"julians37" wrote : Since there's been no follow-up,
|
Sorry have been travelling all last week!
anonymous wrote :
| 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.
anonymous wrote :
| 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.
anonymous wrote :
| 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.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4090013#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...