>>>> For sync we would want to invoke directly to avoid context switching.You're right, there's one important difference between putAsync and put
>>> 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.
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.
This is an important notice! Locking would complicate the design a lot,
>
> 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.
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.
Nevermind the futures, this is not the important part. It's not about
>
>> +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.
async transport neither, it's about async executors.
(okay, the thread was about dropping async transport, I have hijacked it)
Radim
_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev