5 Replies Latest reply on Jun 8, 2009 10:10 AM by Joshua Tharp

    Configuring Local and Remote JMS

    Joshua Tharp Newbie

      It seems like this should be pretty easy, and it probably is, but...

      I'm trying to configure a JBoss 5.0.1.GA instance to use both it own local JBM instance as well as connect to a remote JBoss 5.0.1.GA instance (also using JBM). Ultimately I want to be able to use EJB3 MDBs on local and remote queues and topics I've tried using the configurations I've found on the Wiki, and net which all basically look like this:

      <mbean code="org.jboss.jms.jndi.JMSProviderLoader"
       <attribute name="ProviderName">DFMJMSProvider</attribute>
       <attribute name="ProviderAdapterClass">org.jboss.jms.jndi.JNDIProviderAdapter</attribute>
       <!-- The connection factory -->
       <attribute name="FactoryRef">java:/XAConnectionFactory</attribute>
       <!-- The queue connection factory -->
       <attribute name="QueueFactoryRef">java:/XAConnectionFactory</attribute>
       <!-- The topic factory -->
       <attribute name="TopicFactoryRef">java:/XAConnectionFactory</attribute>
       <!-- Connect to JNDI on the host "localhost" port 1199 -->
       <attribute name="Properties">

      by appending the above to my otherwise unchanged deploy\messaging\jms-ds.xml file.

      When just starting JBoss, with no application deployed, everything seems happy. At least there are no warning or error messages logged. However, when I deploy a simple MDB that tries to connect to the remote topic, I get a Exceptions culminating in this one:
       Deployment "vfsfile:/C:/tools/jboss/jboss-5.0.1.GA/server/standard/deploy/messaging/jms-ds.xml"
       is in error due to the following reason(s): java.lang.IllegalStateException:
       jboss.messaging:name=JMSProvider,service=JMSProviderLoader is already installed.

      I also saw one suggestion to add a tx-connection-factory and so I have also appended this to the same jms-ds.xml file:
       <adapter-display-name>DFM JMS Adapter</adapter-display-name>

      I am shooting in the dark at this point as I cannot find any examples or documentation that describes how to have both a local and remote provider.

      Thanks for your help,


        • 1. Re: Configuring Local and Remote JMS
          Joshua Tharp Newbie

          Correction on the previous post: The Exception occurs whether my app has been deployed or not.

          My MDB's annotations look like this:

          @MessageDriven(activationConfig = {
           propertyName = "destinationType",
           propertyValue = "javax.jms.Topic"),
           propertyName = "destination",
           propertyValue = "topic/noticeTopic"),
           propertyName = "providerAdapterJNDI",
           propertyValue = "DFMJMSProvider")

          • 2. Re: Configuring Local and Remote JMS
            Peter Johnson Master

            This error:

            java.lang.IllegalStateException: jboss.messaging:name=JMSProvider,service=JMSProviderLoader is already installed.

            means that there is already an mbean by that name - which there is - the first entry in the jms-ds.xml file. To get rid of the error, use a different mbean name. There is nothing magical about the name - you could call it something like "cpslo:provider=remote" and it should work just fine.

            I don't know if above advice will get the remote access working, but it should eliminate the error message.

            • 3. Re: Configuring Local and Remote JMS
              Joshua Tharp Newbie

              You're right. That got rid of my error. Now my jms-ds.xml looks like this:

              <?xml version="1.0" encoding="UTF-8"?>
              ...as provided in JBoss distro...
               <attribute name="ProviderName">
               <attribute name="ProviderAdapterClass">
               <!-- The connection factory -->
               <attribute name="FactoryRef">XAConnectionFactory</attribute>
               <!-- The queue connection factory -->
               <attribute name="QueueFactoryRef">XAConnectionFactory</attribute>
               <!-- The topic factory -->
               <attribute name="TopicFactoryRef">XAConnectionFactory</attribute>
               <!-- Connect to JNDI on the host "localhost" port 1199 -->
               <attribute name="Properties">

              Note: I've removed the tx-connection-factory that I had previously added to jms-ds.xml, but the original tx-connection-factory XML is still there.

              The descriptor and my application both deploy now without error. However, I'm still not getting any messages delivered to my MDB. It seems, however, that the two instances of JBoss are talking at some level as bringing down my client instance causes this stacktrace in the remote JMS server.
              14:33:54,649 WARN [Dispatcher] Cannot find object with id pk-xdxg47vf-1-apahx6vf-hj5iam-n6dm1r3 to register
              14:33:54,649 ERROR [ExceptionUtil] ConnectionEndpoint[8k-9vwg47vf-1-apahx6vf-hj5iam-n6dm1r3] close [kl-1m4k47vf-1-apahx6vf-hj5iam-n6dm1r3]
               at org.jboss.jms.server.endpoint.ServerConsumerEndpoint.localClose(ServerConsumerEndpoint.java:542)
               at org.jboss.jms.server.endpoint.ServerSessionEndpoint.localClose(ServerSessionEndpoint.java:1151)

              Any ideas on getting topic messages delivered? I can verify that they are being posted to the remote server's topic as an MDB local to it receives and logs the messages.

              • 4. Re: Configuring Local and Remote JMS
                Adrian Brock Master

                Use the JBoss Messaging Forum/FAQ for this question.

                • 5. Re: Configuring Local and Remote JMS
                  Joshua Tharp Newbie

                  I posted in both places since I had read a message on that board that said a different poster's question belonged on this board since it was dealing with the connection-factories.

                  For the archives: I was able to get it to work once I moved the mbean description into its own file and out of the jms-ds.xml file. I was told it should work in either place, but I ran out of time trying to figure out why it wasn't working for me to combine them. Besides, having a separate file makes it easier to deploy and manage, so it is a better solution anyway.