[jboss-user] [JBoss Messaging] - Re: ClientCallback Multiplex

[aslak]

Sorry for the slow response on this, but I've finally gotten the time to look more into the issue. 
It's the same issue mentioned in this post: 
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=119302


A solution to the problem is to add Persistence to the XMBean desc and generate a serverPeerID if not already set.
This would remove the need for manual serverPeerId configuration, but still keep the option to set it if needed. In the case where a node is moved to a new server and one would want to keep the messages, one could either set the generated serverPeerId in the mbean xml or copy over the xmbean persistence data.

Something like this should work (not widely tested):

  | Index: src/etc/xmdesc/ServerPeer-xmbean.xml
  | ===================================================================
  | --- src/etc/xmdesc/ServerPeer-xmbean.xml	(revision 3286)
  | +++ src/etc/xmdesc/ServerPeer-xmbean.xml	(working copy)
  | @@ -4,6 +4,11 @@
  |        "http://www.jboss.org/j2ee/dtd/jboss_xmbean_1_2.dtd">
  |  <mbean>
  |     <description>JBoss Messaging Server Peer</description>
  | +   <descriptors>
  | +      <persistence persistPolicy="OnUpdate"/>
  | +      <persistence-manager value="org.jboss.mx.persistence.DelegatingPersistenceManager"/>
  | +   </descriptors>
  | +
  |     <class>org.jboss.jms.server.ServerPeer</class>
  |  
  |     <!-- Managed constructors -->
  | Index: src/main/org/jboss/jms/server/ServerPeer.java
  | ===================================================================
  | --- src/main/org/jboss/jms/server/ServerPeer.java	(revision 3286)
  | +++ src/main/org/jboss/jms/server/ServerPeer.java	(working copy)
  | @@ -35,6 +35,7 @@
  |  import java.util.Map;
  |  import java.util.Set;
  |  import java.util.StringTokenizer;
  | +import java.util.UUID;
  |  
  |  import javax.management.Attribute;
  |  import javax.management.InstanceNotFoundException;
  | @@ -218,9 +219,15 @@
  |              return;
  |           }
  |           
  | +         // if no serverPeerID is set manually, generate one.
  |           if (serverPeerID < 0)
  |           {
  | -            throw new IllegalStateException("ServerPeerID not set");
  | +            //throw new IllegalStateException("ServerPeerID not set");
  | +        	 serverPeerID = generateServerPeerID();
  | +        	 // set the ServerPeerID via the MBeanServer to trigger a Persistence if configured 
  | +        	 this.server.setAttribute(
  | +        			 this.serviceName, 
  | +        			 new Attribute("ServerPeerID", new Integer(serverPeerID)));
  |           }
  |  
  |           log.debug(this + " starting");
  | @@ -1393,6 +1400,15 @@
  |        }
  |     }
  |  
  | +   // Generate a ServerPeerId, do not return < 0 
  | +   private int generateServerPeerID() {
  | +		int serverId = UUID.randomUUID().hashCode();
  | +		if(serverId < 0) {
  | +			serverId = generateServerPeerID();
  | +		}
  | +		return serverId;
  | +	}
  | +
  |     private String deployDestinationDefault(boolean isQueue, String name, String jndiName)
  |        throws Exception
  |     {
  | 
  | 


MessageXAResource uses the ServerPeerID to identify the uniqueness of the resource manager in the isSameRM method. This could be changed to use a more unique variable, ip/vmid/serverpeer hashcode? This is likely to fix the cluster 1 to cluster 2 type communication, as long as they do not use the same database backend.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4105056#4105056

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4105056