This is in relation to https://jira.jboss.org/jira/browse/JBMESSAGING-1274 Problem: The problem is currently that many customers start their systems(default peer id is 0) and they have a problem. The error message states that there are two peers with node 0 as the peer. They then look up the error and figure out that they either need to set the environment variable or manually adjust the peer id. But the problem is by the point they get the duplicate peer id message, the database is already hosed. If the peers are started at the same time, they generate channel id's using node 0. So you have two datastores with the same node id and different channel ids. This creates an error condition where you just have to wipe away your database. This entire thing can be avoided if users could use the old jboss paradigm. In order to start a cluster, just start jboss on different nodes in the same network and they will join. This would require something else as the peer id, other than the default 0. Possible Solution to this problem: We could change the peer id to a string field.(db would need changing). So how does the peer id being a string help us here. It helps us because we can then ping something that is naturally occuring in the environment to be that peer id. One thing that comes to mind is bind_address ${bind_address}. The bind address could be used as the peer id, or anything else that is in the environment. But right now there are very few int type things available in the environment. This would also pave the way for a possible future fix to add a programatic peer id designation based on things such as mac address, or other things that will uniquely identify the peer. Jay:) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180864#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...