[timfox]

If you can come up with a solution that doesn't require each node to have a unique server id then we're all ears.

Believe me, it's not trivial or we would have done it already.

[julians37]

I'm not saying that it's trivial, much less that I have a solution, just that the current situation is not ideal...

Anyway, how about the following:

- Allow ServerPeerID to be a string, not just an integer
- Have the default value in messaging-service.xml be something like "${jboss.group.name}_${jboss.bind.address}_${jboss.server.name}_0"

This is obviously not ideal because jboss.bind.address could be 0.0.0.0 and because it doesn't take into account multiple servers running on one host (should include some kind of TCP/IP port number).... but you get the general idea.

[julians37]

Since there's been no follow-up, let me quickly summarize this issue from my point of view:

First of all, your advice of using unique ServerPeerIDs across the board fixed this issue for me, and in my environment it is a viable solution. So let me say thanks a lot for sticking with me and helping me track this one down, I appreciate your help and patience very much.

From this point on it's not about solving a problem of mine but rather I'm just making suggestions as to how JBM as a product could become better by making its setup and its interoperation with other JBM providers smoother.

All I'm saying is that from my point of view, the requirement of having to explicitly assign unique IDs to nodes in a cluster is cumbersome to begin with, but having to make sure they are unique across clusters appears unfortunate. I do not have a personal interest in getting this improved but I would suggest to look into ways of simplifying the configuration process.

Speaking with my limited background on JBM internals, one approach might be to try and take into account more information than the ServerPeerID. The partition a node is part of could be one such piece of information. Whether a node is clustered at all could be another since if it's not, there is no point in assuming a peer could be the same as "this" node.

Another approach might be to not default the ServerPeerID to a numeric constant but rather, if that's possible at all, to a string identifier derived from information such as an external interface address of localhost and possibly a port number.

At any rate, thanks once more for your patience and your advice and I'm sorry should my last posts have come off as confrontational.

All the best,

Julian

[timfox]

"julians37" wrote:
Since there's been no follow-up,

Sorry have been travelling all last week!

From this point on it's not about solving a problem of mine but rather I'm just making suggestions as to how JBM as a product could become better by making its setup and its interoperation with other JBM providers smoother.

Yes, this is certainly something we should strive for.

All I'm saying is that from my point of view, the requirement of having to explicitly assign unique IDs to nodes in a cluster is cumbersome to begin with, but having to make sure they are unique across clusters appears unfortunate.

Agreed.

Speaking with my limited background on JBM internals, one approach might be to try and take into account more information than the ServerPeerID. The partition a node is part of could be one such piece of information. Whether a node is clustered at all could be another since if it's not, there is no point in assuming a peer could be the same as "this" node.

Another approach might be to not default the ServerPeerID to a numeric constant but rather, if that's possible at all, to a string identifier derived from information such as an external interface address of localhost and possibly a port number.

We should certainly revisit this for JBM 2.0.

Current server peer id is also used to key message data in the database as well as transactions on the client side, so the id needs to be permanent for the lifetime of the data. This is one of the reasons we can't just use something like a hostname, ip address, partition name combination since these might change.

One possibility we would be to generate a string GUID representing the node id when a new node is deployed. This then gets automatically written into the config file and stays with it permanently.