I have now tried to reproduce the issue in a standalone unit test and have succeeded to at least some extent =) I am now running two caches locally where one is producing data and the other one is inspecting the cache - causing data to gravitate to the second cache. The issue is replicated in the sense that the produces does get a buddy backup node for itself, but I can't seem to get that node to contain any data. The standalone test is much simpler and single threaded compared to the real life application so thats a plausible reason why we do not see the exact same behaviour (i.e. data inside the redundant buddy backup node). In short: The producer (master) is started: Master created: 192.168.1.135:51469 The slave joins the cluster and is added as a buddy to the master: MASTER: | null {} | /1 {1=c6m0p888dfvz} | /_BUDDY_BACKUP_ {} | /192.168.1.135_51470 {} The slave fetches cache contents and data is gravitated to the slave, thus moving to the slave buddy backup. But we also see the master having a buddy backup for itself (with no data): MASTER: | null {} | /_BUDDY_BACKUP_ {} | /192.168.1.135_51469 {} | /192.168.1.135_51470 {} | /1 {1=c6m0p888dfvz} The backup node for itself does not contain any data like in our real application but I think it might be symptomatic for the issue. You can find the full logfiles here: http://www.cubeia.com/misc/cache/log You can find the source code for the test here:http://www.cubeia.com/misc/cache Warning, the code is a bit of a hack =) To run it, start one instance with the argument 'master' and then another instance with the argument 'slave' directly after. I've put some system properties used in the javadoc of the main class. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4116710#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...