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

Radim Vansa rvansa at redhat.com
Fri Jan 31 07:35:21 EST 2014


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

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.

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;
}

Radim

On 01/31/2014 11:48 AM, Tristan Tarrant wrote:
> Couldn't this be handled higher up in our implementatoin then ?
>
> If I enable an async mode, all puts / gets become putAsync/getAsync
> transparently to both the application and to the state transfer.
>
> Tristan
>
> On 01/31/2014 08:32 AM, Dennis Reed wrote:
>> It would be a loss of functionality.
>>
>> As a common example, the AS web session replication cache is configured
>> for ASYNC by default, for performance reasons.
>> But it can be changed to SYNC to guarantee that when the request
>> finishes that the session was replicated.
>>
>> That wouldn't be possible if you could no longer switch between
>> ASYNC/SYNC with just a configuration change.
>>
>> -Dennis
>>
>> On 01/31/2014 01:08 AM, Galder Zamarreño wrote:
>>> Hi all,
>>>
>>> The following came to my mind yesterday: I think we should ditch ASYNC modes for DIST/REPL/INV and our async cache store functionality.
>>>
>>> Instead, whoever wants to store something asyncronously should use asynchronous methods, i.e. call putAsync. So, this would mean that when you call put(), it's always sync. This would reduce the complexity and configuration of our code base, without affecting our functionality, and it would make things more logical IMO.
>>>
>>> WDYT?
>>>
>>> Cheers,
>>> --
>>> Galder Zamarreño
>>> galder at redhat.com
>>> twitter.com/galderz
>>>
>>> Project Lead, Escalante
>>> http://escalante.io
>>>
>>> Engineer, Infinispan
>>> http://infinispan.org
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


-- 
Radim Vansa <rvansa at redhat.com>
JBoss DataGrid QA



More information about the infinispan-dev mailing list