This is in relation to https://jira.jboss.org/jira/browse/JBMESSAGING-1274
But the problem is by the point they get the duplicate peer id message, the database is already hosed.
Wouldn't be easier to avoid the database on HSQL from being damaged than making any substantial re-engineering or refactorings on JBM 1.4?
IMO Changing the ServerPeerID on JBM 1.4 from an Integer to a String is technically possible but is unlikely to be done. That would change all the testcases on clustering, it would require extensive testing, for the cost of something that won't ever be used in production. In other words, it would diverge all of us from JBM2.
We need to avoid the temptation of creating something that would look like a JBM 1.5.
If you avoided the DB from being corrupted as you're saying, the user would just have to restart the server with the correct ID.
The main reason why server peer id is not a string, is it's used in the PK of tables in the schema.
Making it a string would increase DB size and slow things down.
Ints are very difficult (if not impossible) to make globally unique without getting them from some shared counter (e.g. using JGroups).
Also the id must be unique - for the life time of the server, not just on a single run, so would need to be persisted after generating.
It's hard to see what we could do here, and, as Clebert says, if we were to make a change from int to string it would be a big change and unlikely to happen in 1.4 which is maintenance mode.