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