On Mon, Feb 3, 2014 at 6:28 PM, Radim Vansa <[email protected]> wrote:
> >>>> For sync we would want to invoke directly to avoid context switching. > >>> I think you haven't properly understood what I was talking about: the > >>> putAsync should not switch context at all in the ideal design. It > should > >>> traverse through the interceptors all the way down (logically, in > >>> current behaviour), invoke JGroups async API and jump out. Then, as > soon > >>> as the response is received, the thread which delivered it should > >>> traverse the interceptor stack up (again, logically), and fire the > future. > > A Future doesn't make much sense with an async transport. The problem > > is with an async transport you never get back a response so you never > > know when the actual command is completed and thus a Future is > > worthless. The caller wouldn't know if they could rely on the use of > > the Future or not. > > You're right, there's one important difference between putAsync and put > with async transport: in the first case you can find out when the > request is completed while you cannot with the latter. Not requiring the > ack can be an important optimization. I think that both versions are > very valid: first mostly for bulk operations = reduction of latency, > second for modifications that are acceptable to fail without handling that. > I had the first case in my mind when talking about async operations, and > there the futures are necessary. > A couple more differences: 1. You can't do commitAsync(), but you can configure the commit to be replicated asynchronously (1PC). Although we did talk about removing that option... 2. If you do putAsync(k, v1); putAsync(k, v2), there is no ordering between the two and you might end up with k=v1 in the cache. > > > > Also it depends what you are trying to do with async. Currently async > > transport is only for sending messages to another node, we never think > > of when we are the owning node. In this case the calling thread would > > have to go down the interceptor stack and acquire any locks if it is > > the owner, thus causing this "async" to block if you have any > > contention on the given key. The use of another thread would allow > > the calling thread to be able to return immediately no matter what > > else is occurring. Also I don't see what is so wrong about having a > > context switch to run something asynchronously, we shouldn't have a > > context switch to block the user thread imo, which is very possible > > with locking. > > This is an important notice! Locking would complicate the design a lot, > because the thread in "async" mode should do only tryLocks - if this > fails, further processing should be dispatched to another thread. Not > sure if this could be implemented at all, because the thread may be > blocked inside JGroups as well (async API is about receiving the > response asynchronously, not about sending the message asynchronously). > > I don't say that the context switch is that bad. My concern is that you > have a very limited amount of requests that can be processed in > parallel. I consider a "request" something pretty lightweight in concept > - but one thread per request makes this rather heavyweight stuff. > We did talk in Farnborough/Palma about removing the current LockManager with a queue-based structure like the one used for ordering total-order transactions. And about removing the implicit stack in the current interceptor stack with an explicit stack, to allow resuming a command mid-execution. But the feeling I got was that neither is going to make it into 7.0. > > > > >> +1 much cleaner, I love it. Actually wasn't aware the current code > >> didn't do this :-( > > This is what the current async transport does, but it does nothing with > Futures. > > Nevermind the futures, this is not the important part. It's not about > async transport neither, it's about async executors. > (okay, the thread was about dropping async transport, I have hijacked it) > > Radim > > -- > Radim Vansa <[email protected]> > JBoss DataGrid QA > > _______________________________________________ > infinispan-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev >
_______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
