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

[Radim Vansa]

>>>> 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.

>
> 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.

>
>> +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