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

[Radim Vansa]

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.

Radim