In general, I think shifting to a pull approach using the same process as the other state transfer types is the right thing to do. One set of code to maintain, etc, etc. The following bits look like I'm arguing in the opposite direction, but takes that as "food for thought", i.e. inputs into the discussion. There are a couple problems with using a regular pull-type state transfer: 1) Deadlock problems, which is what led last spring to the push approach. Problem is new cache C comes online, decides A and B are its buddies, so sends A and B an RPC telling them. A and B get the RPC and request state. Problem is they are using the JG up_thread to request state, so it deadlocks. That's probably solvable, but at the cost of making the buddy group formation protocol more complex. 2) A and B now have to independently request state rather than C doing a single push. Don't know if there are any issues with the coordination involved there. Now that we are using anycast, the network utilization is likely the same either way. One thing to think about is whether the JBC-315 issue applies here. Or can it be made to go away w/o relying on FLUSH? Here the data in question is *owned* by the node that sends it. Anything that changes that state is originating on that server -- either via a locally originating put/remove call, or via a response to a gravitation call that the node sent out. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995496#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...