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

[Sanne Grinovero]

On 3 February 2014 14:10, Radim Vansa <rvansa at redhat.com> wrote:
> See below...
>
> On Fri, Jan 31, 2014 at 7:35 AM, Radim Vansa <rvansa at 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.

+1 much cleaner, I love it. Actually wasn't aware the current code
didn't do this :-(

Sanne

>
> Radim
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev