[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jboss-user
Subject:    [jboss-user] [JBoss Messaging] - Re: Bridge cannot find session
From:       timfox <do-not-reply () jboss ! com>
Date:       2007-09-30 9:37:19
Message-ID: 19993840.1191145039247.JavaMail.jboss () colo-br-02 ! atl ! jboss ! com
[Download RAW message or body]

"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#4090013

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4090013
 _______________________________________________
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user


[prev in list] [next in list] [prev in thread] [next in thread]