On 31/01/14 13:35, Radim Vansa 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).
+1000, I should have read the entire thread before replying... :-)
>
> 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
>>>> gal...@redhat.com
>>>> twitter.com/galderz
>>>>
>>>> Project Lead, Escalante
>>>> http://escalante.io
>>>>
>>>> Engineer, Infinispan
>>>> http://infinispan.org
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>
>
--
Bela Ban, JGroups lead (http://www.jgroups.org)
_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
