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
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4087851#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...