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, 24 May 2018 10:57:18 GMT
So, in a current implementation, how I can perform the real async operation
in one thread? Any workaround?
What can I do if I have event loop thread model?

On Wed, May 16, 2018 at 12:14 PM, Alexey Goncharuk <
alexey.goncharuk@gmail.com> wrote:

> Dmitriy,
>
> I will add technical details to the ticket, however, looks like there is
> still no consensus on how this change should be presented to a user. It
> would be ok if we changed this behavior in Ignite 3.0, but for one of the
> next point releases we have to agree how this should be enabled/disabled
> (or whether we should delay this change to 3.0 at all).
>
> 2018-05-15 22:13 GMT+03:00 Dmitriy Govorukhin <
> dmitriy.govorukhin@gmail.com>
> :
>
> >  Alexey,
> >
> > Any updates?
> >
> > On Mon, May 14, 2018 at 6:19 PM, Dmitriy Govorukhin <
> > dmitriy.govorukhin@gmail.com> wrote:
> >
> > > Alexey,
> > >
> > > Could you please add more description information for this task? [1]
> > > Perhaps, base steps for implementation.
> > >
> > > [1] https://issues.apache.org/jira/browse/IGNITE-8475
> > >
> > > On Mon, May 14, 2018 at 4:58 PM, Alexey Goncharuk <
> > > alexey.goncharuk@gmail.com> wrote:
> > >
> > >> Another +1 for the true asynchronous approach. I remember a while ago
> > one
> > >> of the Ignite users raised a similar question regarding the *async
> > method
> > >> being blocked on establishing a TCP connection.
> > >>
> > >> As far as deadlocks go, I have a counter-example. Currently, we check
> > the
> > >> thread-local chain only for a single cache, so if I run the following
> > >> code:
> > >> cache1.getAsync(k1);
> > >> cache2.getAsync(k2);
> > >> then the deadlock is still possible, and I did not see a single user
> > >> complaining about unexpected deadlocks. Rather than implementing this
> > >> cross-cache chain (which would probably add another overhead), I would
> > >> make
> > >> it consistent and allow operations to be run in parallel.
> > >>
> > >> There are many use-cases when having true async operations
> dramatically
> > >> improve performance. Consider, for example, a streaming example when
> > keys
> > >> are being pushed by a client to a cluster. Currently, to run effective
> > >> processing, the user will have to use a data streamer with custom keys
> > >> receiver which may be a huge usability downside. Async operations can
> > >> utilize the cluster resources very efficiently.
> > >>
> > >> Finally, if we want to be on the safe side, we can keep the operation
> > >> chain
> > >> inside a transaction. I see absolutely no point in maintaining this
> > chain
> > >> outside of transactions.
> > >>
> > >> --AG
> > >>
> > >> 2018-05-14 16:01 GMT+03:00 Dmitriy Govorukhin <
> > >> dmitriy.govorukhin@gmail.com>
> > >> :
> > >>
> > >> > Andrey,
> > >> >
> > >> > Do you prefer change behavior at runtime?
> > >> > I guess will be better have different methods for getting cache
> > instance
> > >> > with fair and not fair sync.
> > >> >
> > >> > On Mon, May 14, 2018 at 3:39 PM, Andrey Gura <agura@apache.org>
> > wrote:
> > >> >
> > >> > > +1 for fair async operations.
> > >> > >
> > >> > > But I don't like idea use withFairSync() method. We added
> xxxAsync()
> > >> > > methods recently and withAsync() is deprecated.
> > >> > >
> > >> > > I think we should just make methods are async in nature and
> provide
> > >> > > ability of switching to the old behaviour using flag or property.
> > >> > >
> > >> > > On Fri, May 11, 2018 at 11:00 PM, Dmitriy Setrakyan
> > >> > > <dsetrakyan@apache.org> wrote:
> > >> > > > Vladimir,
> > >> > > >
> > >> > > > In general I agree, but I do get greatly *close-minded*
(pun
> > >> intended)
> > >> > > > whenever users' code that worked for the past several years
all
> > of a
> > >> > > sudden
> > >> > > > gets deadlocked after an upgrade. Making this feature optional
> is
> > >> even
> > >> > > > worse and more confusing. In this case the best action is
no
> > action
> > >> at
> > >> > > all.
> > >> > > >
> > >> > > > BTW, would be interesting to find out how Oracle async driver
> > >> behaves
> > >> > in
> > >> > > > this case.
> > >> > > >
> > >> > > > D.
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > > On Fri, May 11, 2018 at 8:29 PM, Vladimir Ozerov <
> > >> vozerov@gridgain.com
> > >> > >
> > >> > > > wrote:
> > >> > > >
> > >> > > >> Guys,
> > >> > > >>
> > >> > > >> To build a great product we should be open minded and
look to
> the
> > >> > > future,
> > >> > > >> not to the past.
> > >> > > >>
> > >> > > >> Dima raised very valid point - why async is not async?
Current
> > >> > > programming
> > >> > > >> culture and demanding performance requirements pushes
users
> > towards
> > >> > > >> reactive-style programming. I do not want my thread
to ever be
> > >> > blocked.
> > >> > > >> Instead, I want to send a number of concurrent commands
and
> > >> optionally
> > >> > > >> subscribe to final result. So trully async API makes
total
> sense
> > to
> > >> > me.
> > >> > > >>
> > >> > > >> But personally, my primary interest in this area is
SQL. Oracle
> > is
> > >> > > >> preparing new async driver. ADBA - async database access.
It
> was
> > >> > > presented
> > >> > > >> on recent JavaOne [1]. It is under active development
right
> now -
> > >> juse
> > >> > > >> weave through the mailing list [2]. Some prototypes
are already
> > >> there
> > >> > > [3].
> > >> > > >> PostgreSQL community even started adopted it [4]!
> > >> > > >>
> > >> > > >> I am not pushing for immediate actions, but at least
we should
> > >> > > understand
> > >> > > >> which way the wind is blowing. As a mid-term goals I
would
> > propose
> > >> to
> > >> > > >> finally remove thread ID from our PESSIMISTIC transactions
to
> > allow
> > >> > for
> > >> > > >> suspend/resume in different threads. And as a next step
I would
> > >> think
> > >> > on
> > >> > > >> adopting async cache and SQL APIs.
> > >> > > >>
> > >> > > >> Vladimir.
> > >> > > >>
> > >> > > >> [1]
> > >> > > >> http://www.oracle.com/technetwork/database/
> > >> > > application-development/jdbc/
> > >> > > >> con1491-3961036.pdf
> > >> > > >> [2] http://mail.openjdk.java.net/pipermail/jdbc-spec-discuss/
> > >> > > >> [3] https://github.com/oracle/oracle-db-examples/tree/master/
> > >> java/AoJ
> > >> > > >> [4] https://github.com/pgjdbc/pgjdbc/issues/978
> > >> > > >>
> > >> > > >> On Fri, May 11, 2018 at 9:48 PM, Dmitriy Setrakyan <
> > >> > > dsetrakyan@apache.org>
> > >> > > >> wrote:
> > >> > > >>
> > >> > > >> > On Fri, May 11, 2018 at 7:46 PM, Dmitriy Govorukhin
<
> > >> > > >> > dmitriy.govorukhin@gmail.com> wrote:
> > >> > > >> >
> > >> > > >> > > I will edit IGNITE-8475, and remove all part
that belong to
> > the
> > >> > > public
> > >> > > >> > api.
> > >> > > >> > > Is it acceptable for you?
> > >> > > >> > >
> > >> > > >> >
> > >> > > >> > Everything is acceptable, as long as the public
API is safe
> :)
> > >> > > >> >
> > >> > > >>
> > >> > >
> > >> >
> > >>
> > >
> > >
> >
>

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