[infinispan-dev] [infinispan-internal] async processing documentation (+ nice inconsistency scenario example)

Manik Surtani msurtani at redhat.com
Tue Mar 19 11:17:45 EDT 2013


On 19 Mar 2013, at 15:07, Sanne Grinovero <sanne at redhat.com> wrote:

> 
> 
> ----- Original Message -----
>> 
>> On 19 Mar 2013, at 12:21, Mircea Markus <mmarkus at redhat.com> wrote:
>> 
>>> On 19 Mar 2013, at 11:05, Sanne Grinovero wrote:
>>>> Does Marshalling really need to be performed in a separate thread
>>>> pool?
>>>> I think we have too many pools, too much context switching, and
>>>> situations like this one which should be avoided.
>>>> 
>>>> We could document it  but all these details are making it very
>>>> hard to feel comfortable with, and for this specific use case I
>>>> wonder if there
>>>> is a strong benefit: plain serial operations seem so much cleaner
>>>> to me.
>>> +1 for dropping it in 6.0. It isn't enabled by default and AFAIK it
>>> created more confusion through the users than benefits.
>> 
>> Why?  I don't agree.  If network transfer is the most expensive part
>> of performing a write, then marshalling is the second-most
>> expensive.  If you don't take the marshalling offline as well,
>> you're only realising a part of the performance gains of using
>> async.
> 
> Of course. I didn't mean to put it on the thread of the invoker, I would expect
> this to happen "behind the scenes" when using async, but in the same thread which
> is managing the lower IO so to reduce both context switching and these weird
> race conditions.. so removing the option only.

Well, when using the same lower IO pool, while common sense, isn't as easy since it is a JGroups pool.  If we pass the marshaller itself into JGroups, the marshalling still happens online, and just the IO happening in a separate thread.  Also, JGroups allows you to register one marshaller and unmarshaller per channel - which doesn't work when you have a transport shared by multiple cache instances potentially on different class loaders.

So yes, this can be done much better, but that means a fair few changes in JGroups such that:

* Marshalling happens in the async thread (the same one that puts the message on the wire) rather than in the caller's thread
* sendMessage() should accept a marshaller and unmarshaller per invocation

Then we can drop this additional thread pool.

> 
>> 
>>> On top of that the number of pools is growing (5.3 adds another
>>> pool in the scope of ISPN-2808).
>> 
>> You can configure to use a single thread pool for all these tasks, if
>> hanging on to multiple thread pools is too complex.
> 
> I don't believe you can always do that, if you don't keep tasks isolated
> in different pools deadlocks could happen. So unless you can come up with
> a nice diagram and explain which ones are safe to share, it is very
> complex to handle.
> 
> Would be nice to have these discussions on the public mailing list.

+1.  Adding infinispan-dev in cc.

> 
> Sanne
> 
>> 
>> - M
>> 
>> --
>> Manik Surtani
>> manik at jboss.org
>> twitter.com/maniksurtani
>> 
>> Platform Architect, JBoss Data Grid
>> http://red.ht/data-grid
>> 
>> 
>> 
> 

--
Manik Surtani
manik at jboss.org
twitter.com/maniksurtani

Platform Architect, JBoss Data Grid
http://red.ht/data-grid




More information about the infinispan-dev mailing list