7 Replies Latest reply on Jan 5, 2007 4:52 AM by ovidiu.feodorov

    JBMESSAGING-578 - Multiplex JGroups Channel

    clebert.suconic

      This is a thread discussion on http://jira.jboss.com/jira/browse/JBMESSAGING-578.

      For a call on JChannelFactory, we are supposed to send an ID identifying the system.

      We could have a constant (such as JBOSS_MESSAGING) on that ID, but per my discussion with Brian Stansberry we should have the ID configured.

      Brian Stansberry recomended using ${jboss.partition.name:DefaultPartition}-JMS for the Application Server.

      I will keep the partitionID configurable on the ClusteredPostOfficeMBean then.

        • 1. Re: JBMESSAGING-578 - Multiplex JGroups Channel
          clebert.suconic

          I have a question regarding this:

          Should we aways use JGroups Multiplexor by default, or only when running under JBoss5?



          I'm creating a new interface to perform JChannel creations called ChannelFactory. This interface is only used at DefaultClusteredPostOffice and its service.

          Since I don't want to put everything on the same package as DefaultClusteredPostOffice, I have created a new package under postoffice.cluster, called jgroups which can be easily renamed/moved later if that's not the proper place.


          I haven't committed my changes yet by the time of this post, but I will as soon as I have finished running testcases.

          • 2. Re: JBMESSAGING-578 - Multiplex JGroups Channel
            clebert.suconic

            We will deploy JChannelFactory as part of jboss-messaging.sar for deployment under jboss-4, and we will use the default ChannelFactory under JBoss5.

            I will add /META-INF/multiplexer-stacks.xml under jboss-messaging.sar, to use the exact same location jgroups.sar (forgot the exact name of the package under jboss-5). Under the source tree this will be located under /src/etc/META-INF (this was a perfect location for the testsuite also)

            Also.. as there is an issue with JGroups and IPV6 (as documented on their WIKI page), I will add -Djava.net.preferIPv4Stack=true on ServerManagement.spawn and every start-rmi-clustering-service, as the new stacks introduced by ChannelFactory and multiplexer-stacks.xml are using IPV6.

            • 3. Re: JBMESSAGING-578 - Multiplex JGroups Channel
              brian.stansberry

              Please note that I'm hoping to get the JGroups multiplexer as a standard sar in the 4.2 release -- see http://jira.jboss.com/jira/browse/JBAS-3940.

              • 4. Re: JBMESSAGING-578 - Multiplex JGroups Channel
                clebert.suconic

                Brian... what about this?

                - We lookup for the JChannelFactory MBean...
                - If not found, we create channels as we always used to do.

                In our configurations we would aways have the MBean name by default, and the JGroups stack to be used case the MBean was not found.

                This way, if jboss-messaging is deployed on 4.0, we would use the regular Channel, if on 4.2 or 5 we would use the multiplexor.

                • 5. Re: JBMESSAGING-578 - Multiplex JGroups Channel
                  brian.stansberry

                  JBoss Cache actually basically does it that way. The downside to it is that it masks errors (if the JChannelFactory really should be found). For that reason I'm tempted to change the JBC behavior so it fails if it can't find a configured JChannelFactory. But it sounds like the JBM case is different from JBC in that you have a standard config file that you want to work in multiple environments. JBC doesn't have such a requirement. So, for JBM what you propose sounds reasonable.

                  • 6. Re: JBMESSAGING-578 - Multiplex JGroups Channel
                    timfox

                    I think we can always assume the MBean is there, therefore no need to create the channels ourself.

                    • 7. Re: JBMESSAGING-578 - Multiplex JGroups Channel
                      ovidiu.feodorov

                      Amen.

                      Clebert, I haven't changed a single word with Tim on the subject :)

                      This is re: our previous discussion ... :)