1 Reply Latest reply on Mar 22, 2011 12:00 PM by ryanhos

    Configuring ClusteredConnectionFactory on heterogeneous cluster

    ryanhos

      We have a 40+ node JBoss cluster with 4 distinct server types in the cluster (for simplicity, assume 4 types * 10 instances each).  The server types all handle different jobs, but need to share some queues, so we have JMS clustered between them.  Last week, we exhausted the JMS client pool (JBM_clientMaxPoolSize) on one of the servers, so I added some logic in our provisioning software that builds the 40 nodes to calculate the exact number (plus a margin) needed by each server type, and substitute that value in remoting-bisocket-service.xml. 

       

      Server Type A:

      <attribute name="JBM_clientMaxPoolSize" isParam="true">235</attribute>

       

      Server Type B:

      <attribute name="JBM_clientMaxPoolSize" isParam="true">180</attribute>

       

       

      ..and so forth.

       

      The next time I booted, I got this error from ConnectionFactoryJNDIMapper:

      "[ERROR] [org.jboss.messaging.util.ExceptionUtil] - org.jboss.jms.server.connectionfactory.ConnectionFactory@a605722 startService

      java.lang.IllegalArgumentException: The remoting locator configuration for a particular clustered connection factory must be the same on each node in the cluster. We have detected that the configuration differs on this node. Please correct and redeploy the connection factory"

       

      This indicates to me that the invoker locator string for a clustered connection factory must be the same throughout the cluster (I imagine because this aids in providing failover to a matching locator elsewhere in the cluster.  The JBM_clientMaxPoolSize is part of the invoker locator string because JBoss Messaging ships remoting-bisocket-service.xml with the isParam attribute set to true on that particular XML element. 

       

      So, my question is this:  How do I tune the JBM_clientMaxPoolSize for the non-clustered connection factory per server type, and at the same time allow the clustered connection factory to still function?  Do I set isParam="false" on that attribute so that it doesn't end-up in the invoker locator string (why does the client need this information anyway)?  Do I add annother identical, but differently-named org.jboss.remoting.transport.Connector MBean configuration, with the same value for JBM_clientMaxPoolSize across the entire cluster, and then modify the jboss.messaging.connectionfactory:service=ClusteredConnectionFactory MBean configuration in connection-factories-service.xml to point at the new homogeneous Connector?  I assume that the new connector would require it's own port and binding-service information; is this correct?

        • 1. Configuring ClusteredConnectionFactory on heterogeneous cluster
          ryanhos

          It appears that the parameter is necessary.  JMSRemotingConnection has a hard-coded reference to this property, and complains when it is not present on the InvokerLocator.

           

          I'll update when I have the additional connector configured.  It's too bad the easy path won't work, but the hard path isn't much more difficult.