ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitriy Govorukhin <dmitriy.govoruk...@gmail.com>
Subject Re: async operation is not fair async
Date Thu, 02 Aug 2018 16:54:08 GMT
Folks,
Any comments?
I will start to implement withFairAsync(); decorator soon.

On Wed, Aug 1, 2018 at 12:22 PM Dmitriy Pavlov <dpavlov.spb@gmail.com>
wrote:

> Igniters,
>
> I've re-read this thread in brief. As far as I know this change is not
> coming from some company, so this change will be at least good for healthy
> community building.
>
> And I didn't find any obstacles why not to implement approach with new mode
> .withFairAsync() for cases user is completely aware of consequences.
>
> It could be not public API to avoid anyone will use it. It could be
> used,e.g. in integrations and by qualified users to gain as much
> throutghput as it is possible.
>
> So I would like to be an sponsor here. If anyone or Dmitriy G. will
> contribute this change, I will merge it. I hope PMCs are agree here and
> will not veto this change.
>
> Sincerely,
> Dmitriy Pavlov
>
> чт, 24 мая 2018 г. в 15:13, Yakov Zhdanov <yzhdanov@apache.org>:
>
> > Alexey Goncharuk, I remember we started working on async connection
> > establishment. This should fix latency issue related to network which I
> > believe gives the most contribution to overall latency. Mapping logic and
> > other stuff can be ignored as it can very rarely be an issue at least on
> > stable tolopogies. What is the status with async connections? That would
> > really be a huge improvement!
> >
> > Also please remember that uncontrolled async operations may lead to OOME,
> > therefore at some point when there are too many uncompleted async
> > operations newly invoked async operations should become synchronous, i.e.
> > we should return completed future, ignoring the fact that user expected
> us
> > to be async.
> >
> > I would like to have very strong reasons to start reapproaching this.
> >
> > --Yakov
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message