[infinispan-dev] Ditching ASYNC modes for REPL/DIST/INV/CacheStores?

[Dan Berindei]

On Mon, Feb 3, 2014 at 6:28 PM, Radim Vansa <rvansa at redhat.com> 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 <rvansa at redhat.com>
> JBoss DataGrid QA
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20140203/8e6773f7/attachment.html