Re: [infinispan-dev] Rethinking asynchronism in Infinispan

On 01/13/2010 06:56 PM, Manik Surtani wrote: > > On 13 Jan 2010, at 17:13, Bela Ban wrote: >> We deal with asynchronism in a somewhat haphazard way at the moment, >>> each of these functions receiving a somewhat different treatment: >>> >>> 1) RPC: Using JGroups' ResponseMode of waiting for none. >>> 2) Marshalling: using an async repl executor to take this offline >> >> The problem here is that you're pushing the problem of marshalling >> further down the line. *Eventually* data has to be marshalled, and >> somebody *has* to block ! IIRC, you used a bounded queue to place >> marshalling tasks onto, so for load peaks this was fine, but for >> constant high load, someone will always block on the (full) queue. > > That's where it happens right now. Just before RPC. Now perhaps there is some sense in understanding that more than one subsystem may need a marshalled representation of an entry (e.g., the RpcManager to push across the wire, as well as a CacheStore to persist to disk or network again), so this could happen prior to either of these calls. And also useful to note - as you mention later - that UNmarshalling is often far slower than marshalling, so any sync network calls should not wait for entries to be unmarshalled on the remote end. We provide for this to some degree with the lazyDeserialization config element which makes use of MarshalledValues. It could just be better integrated with the rest of what we are doing re: async. Note that there was also some talk in the past about using MarshalledValues all the time in a email thread called "storing in memory data in binary format" in the infinispan-dev list. This enabled memory based eviction policies.