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

[William Burns]

+1 to moving to the async methods only.  I have mentioned this as well
in passing when discussing L1 as there is no way to ensure consistency
with an async transport.  Although if we fire the async methods with
either SKIP_REMOTE_LOOKUP/IGNORE_RETURN_VALUES flag than this
consistency is still lost as I am guessing some people will want this
to reduce network overhead.

When I thought about this before these were the drawbacks I could think of:

1. Another configuration option that may need to be tweaked (async
executor properties) - although we could then get rid of
AsyncConfiguration so overall less configuration
2. The submitting node would hold memory for a bit longer since it has
to keep the callable in memory during the call instead of until it is
sent through JGroups
3. You can overwhelm the thread pool with requests and use more
threads, technically you could swamp the async transport as well
4. We don't get the benefit of batching requests with the replication queue
5. We have to process the response since we aren't using GET_NONE with
JGroups - although we can't guarantee consistency without doing so

I personally think to reduce complexity of code/configuration and
provide consistency these are probably fine.

Also to note if we moved to async methods it should be faster for any
invoker since it doesn't even have to traverse the interceptor chain
at all in the calling thread (implicit async marshalling).  This also
means that every operation from the same node will not be ordered
using OOB thread pool allowing messages to the same node to operate in
parallel.

 - Will

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.

>
> 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
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev