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