[jbosscache-dev] Multiple Channel.getState() invocations

[Bela Ban]

Vladimir, Jason,

what happens when we have multiple Channel.getState() invocations with 
STREAMING_STATE_TRANSFER ?

Let's say I invoke Channel.getState() once, and then time out waiting 
for the state response. On the state provider, this caused the spawning 
of a thread which handles the state request.

Now I call Channel.getState() the 2nd time. Does this mean that

   1. there is a 2nd thread spawned by the state provider ?
   2. the 2nd Channel.getState() could actually return when the *first*
      state requester thread sends back the state ?

If #1 is true, and we spawn 1 thread per state request, then that means 
we're traversing the tree *once per thread* ! This is probably not a big 
deal in STREAMING_STATE_TRANSFER, because we're only allocating a socket 
and output stream, but we're still traversing the tree once per thread 
and use up CPU cycles for serialization !

Or is this completely wrong and we're just adding an incoming request to 
the request queue if there is already a state transfer request being 
processed ? This is what is done in STATE_TRANSFER, don't know about 
STREAMING_STATE_TRANSFER. Can you verify what's going on here ?

Jason: we  should consider trashing the loop where we call 
Channel.getState() on a member and continue the loop if getState() runs 
into a timeout. I suggest we set the timeout to 0, or at least to a 
large value. This means we'll wait forever for a large state, or return 
with rc=false. This would only be the case e.g. when the state cannot be 
serialized, ie. when hitting a non serializable object.

Thoughts ?

-- 
Bela Ban
Lead JGroups / Clustering Team
JBoss - a division of Red Hat