anonymous wrote : | It seems here that application has data backed up on node3 and node4 (which are from pool2) | What makes you think this is the case? A good way to tell is to use the JMX console on each node and dump cache contents to see where the data is and where the backups are. In your scenario, you have: Pool1: node1, node2 Pool2: node3, node4 When you use the app (assume you start on node2 as your example suggests) your state is backed up on node1 since it is in the same pool. When you kill node2, your app continues to work since the state is available on node1. Now node1 NEEDS a new backup node. Since there are no other nodes in pool1, it is forced to pick a node from elsewhere (such as in pool2). Basically, these pools are only _hints_ on how to select a backup node. The algorithm is: 1) Try and select buddy from same pool, on different host. 2) Else, try and select buddy from same pool, on same host. 3) Else, try and select buddy from different pool, on different host. 4) Else, try and select buddy from different pool, on same host. 5) Finally fall back to no buddy. See NextMemberBuddyLocator.locateBuddies() for details of how this is implemented. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4021080#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...