On Mon, Feb 3, 2014 at 9:54 AM, Sanne Grinovero <sa...@infinispan.org> wrote:
> On 3 February 2014 14:10, Radim Vansa <rva...@redhat.com> wrote:
>> See below...
>>
>> On Fri, Jan 31, 2014 at 7:35 AM, Radim Vansa <rva...@redhat.com> wrote:
>>>> Worth to note that Infinispan does not have true async operation -
>>>> executing synchronous request in another threadpool is rather simplistic
>>>> solution that has serious drawbacks (I can imagine a situation where I'd
>>>> do 100 async gets in parallel, but this would drain the whole threadpool).
>>> I agree if we could optimize this with batching it would make it better.
>>>
>>>> Implementing that would require serious changes in all interceptors,
>>>> because you wouldn't be able to call
>>>>
>>>> visitWhateverCommand(command) {
>>>> /* do something */
>>>> try {
>>>> invokeNextInterceptor(command);
>>>> } finally {
>>>> /* do another stuff */
>>>> }
>>>> }
>>>>
>>>> - you'd have to put all local state prior to invoking next interceptor
>>>> to context. And you'd need twice as many methods, because now the code
>>>> would explicitly traverse interceptor stack in both directions.
>>> I am not quite sure what you mean here. Async transport currently
>>> traverses the interceptors for originator and receiver (albeit
>>> originator goes back up without a response).
>>>
>>>> Still, I believe that this may be something to consider/plan for future.
>>>>
>>>> And then, yes, you'd need just
>>>>
>>>> put(key, value) {
>>>> future = putAsync(key, value);
>>>> return sync ? future.get() : null;
>>>> }
>>> 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.
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.
>
> +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.
>
> Sanne
>
>>
>> Radim
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
