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.goncha...@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.govoruk...@gmail.com> > : > > > Alexey, > > > > Any updates? > > > > On Mon, May 14, 2018 at 6:19 PM, Dmitriy Govorukhin < > > dmitriy.govoruk...@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.goncha...@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.govoruk...@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 <ag...@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 > > >> > > <dsetrak...@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 < > > >> voze...@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 < > > >> > > dsetrak...@apache.org> > > >> > > >> wrote: > > >> > > >> > > >> > > >> > On Fri, May 11, 2018 at 7:46 PM, Dmitriy Govorukhin < > > >> > > >> > dmitriy.govoruk...@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 > :) > > >> > > >> > > > >> > > >> > > >> > > > > >> > > > >> > > > > > > > > >
