6 Replies Latest reply on Mar 20, 2008 4:14 PM by Brian Stansberry

    role of port bindings xml

    Navjeet Newbie

      Using WinXP, JBoss 4.2.1.GA and JBM 1.4.0.SP3

      We have 6 Jboss AS clusters on a machine (each cluster has two nodes on two different machines). We are using port bindings xml file to specify different port binding (ports-default, ports-01....ports-05) for each instance (set of two nodes) in the cluster. We are also using --host and -Djboss.partition.name flags/properties with distinct partition name for each cluster, in startup script of Jboss. Is this setup enough to isolate all 6 clusters including JMS cluster?

        • 1. Re: role of port bindings xml
          Brian Stansberry Master

          No, it is not. The JGroups channels in nodes meant to be part of different clusters will be listening on the same multicast addresses and ports and will thus see each others traffic. The use of -Djboss.partition.name will prevent that traffic from getting out the JGroups channel, but you still don't want that.

          See http://wiki.jboss.org/wiki/Wiki.jsp?page=TwoClustersSameNetwork for more on how to isolate clusters.

          On Windows XP the problem discussed in the "Why isn't it sufficient to change the group name and multicast address? Why do I need to change the multicast port if I change the address?" section of that wiki page doesn't apply. So, simple way to ensure different clusters don't see each others' traffic is to add -u some_multicast_address to the list of params you pass to run.bat. Use a different "some__multicast_address" for each of your 6 clusters.

          • 2. Re: role of port bindings xml
            Navjeet Newbie

            Thanks for that info, Brian.

            Is there any resource online that can provide info on what settings in which files (e.g. cluster-service.xml, hajndi-jms-ds.xml etc.) are being overridden when one specifies port setting (ports-default, ports-01 etc.) in jboss-service.xml. There seems to be ports specified in so many configuration files for different services and I just want to be sure that I DO or DO NOT need to tokenize those ports.

            • 3. Re: role of port bindings xml
              Brian Stansberry Master

              If you look at the jboss-service.xml mbean where you set ports-01, etc, there's a "StoreURL" attribute:

              <mbean code="org.jboss.services.binding.ServiceBindingManager"
               <attribute name="ServerName">ports-01</attribute>
               <attribute name="StoreURL">${jboss.home.url}/docs/examples/binding-manager/sample-bindings.xml</attribute>
               <attribute name="StoreFactoryClassName">

              That tells you the location under the root of your JBoss install where it finds the file it uses to alter the ports. You can look at that file to see what it is doing. You'll have to think about/interpret it, as it isn't documentation.

              • 4. Re: role of port bindings xml
                Navjeet Newbie

                I have setup the clusters and I am passing -c, -b, -g and -u parameters (with unique values for the clusters) in the run script. I am using JMS to send message from one cluster to another and it is picked up by the third cluster also. I am using a JMS bridge for that and assuming (I think that is true) that the bridge is setup properly. Is there anyway to verify the nodes involved in JMS cluster from jmx console? If you think this is a JMS setup issue let me know and I will ping that mailing list. I wanted to make sure there is no cluster setup issue before I went that path.

                • 5. Re: role of port bindings xml
                  Navjeet Newbie

                  BTW this test was performed on Windows Server 2003.

                  • 6. Re: role of port bindings xml
                    Brian Stansberry Master

                    You can see who the members of a cluster are by looking at the jboss:service=DefaultPartition mbean in jmx-console. Except, replace "DefaultPartition" with whatever you set with -g.

                    Re: your JMS issue, I'm guessing someone is looking up a ConnectionFactory from the wrong cluster; i.e. a config issue in someone's naming properties.