2 Replies Latest reply on Aug 11, 2016 3:05 PM by Justin Bertram

    Problems connecting from standalone client to ActiveMQ Queue (migrating from wildfly 9 to 10)

    choesang tenzin Newbie

      I am running a java standalone client (not running inside wildfly) which is connecting to a Widlfly JMS queue.

      The client was previously working with wildfly 9.0.2.FINAL and i am now trying to upgrade to wildfly 10.0.0.FINAL

       

      standalone-full.xml

      <subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0">
                  <server name="default">
                      <journal file-size="102400"/>
                      <transaction scan-period="30000" timeout="600000"/>
                      <shared-store-master/>
                      <security-setting name="#">
                          <role name="guest" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/>
                      </security-setting>
                      <address-setting name="#" message-counter-history-day-limit="10" page-size-bytes="2097152" max-size-bytes="10485760" expiry-address="jms.queue.ExpiryQueue" dead-letter-address="jms.queue.DLQ"/>
                      <http-connector name="http-connector" endpoint="http-acceptor" socket-binding="http"/>
                      <http-connector name="http-connector-throughput" endpoint="http-acceptor-throughput" socket-binding="http">
                          <param name="batch-delay" value="50"/>
                      </http-connector>
                      <in-vm-connector name="in-vm" server-id="0"/>
                      <http-acceptor name="http-acceptor" http-listener="default"/>
                      <http-acceptor name="http-acceptor-throughput" http-listener="default">
                          <param name="batch-delay" value="50"/>
                          <param name="direct-deliver" value="false"/>
                      </http-acceptor>
                      <in-vm-acceptor name="in-vm" server-id="0"/>
                      <jms-queue name="ExpiryQueue" entries="java:/jms/queue/ExpiryQueue"/>
                      <jms-queue name="DLQ" entries="java:/jms/queue/DLQ"/>
                      <jms-queue name="xrun" entries="java:/jms/xrunQueue java:jboss/exported/jms/xrunQueue"/>
                      <jms-topic name="xrun" entries="java:/jms/xrunTopic java:jboss/exported/jms/xrunTopic"/>
                      <jms-topic name="Jobs" entries="java:/jms/Jobs java:jboss/exported/jms/Jobs"/>
                      <connection-factory name="InVmConnectionFactory" consumer-window-size="0" entries="java:/ConnectionFactory" connectors="in-vm"/>
                      <connection-factory name="RemoteConnectionFactory" consumer-window-size="0" reconnect-attempts="-1" connection-ttl="-1" entries="java:jboss/exported/jms/RemoteConnectionFactory" connectors="http-connector"/>
                      <pooled-connection-factory name="activemq-ra" transaction="xa" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory" connectors="in-vm"/>
                  </server>
              </subsystem>
      

       

      Here is my JNDI properties

      java.naming.provider.url=tcp://wildfly:8111
      java.naming.factory.initial=org.apache.activemq.artemis.jndi.ActiveMQInitialContextFactory
      java.naming.security.principal=JMS_USER
      java.naming.security.credentials=JMS_PASSWORD
      


      Client code that does a JNDI lookup

      String connectionFactoryString = System.getProperty("connection.factory", "jms/RemoteConnectionFactory");
      connectionFactory = (ConnectionFactory) namingContext.lookup(connectionFactoryString);
      

       

      The JNDI lookup throws a NamingException and fails to connect to the JMS queue.

       

      I have tried changing the connectionFactoryString to "ConnectionFactory" as stated in the Artemis documentation Using JMS | ActiveMQ Artemis Documentation

      ConnectionFactory cf = (ConnectionFactory)ic.lookup("ConnectionFactory");

       

      Tried using both

      java.naming.provider.url=http-remoting://wildfly:8111

      java.naming.provider.url=tcp://wildfly:8111


      I dont get any ClassNotFoundExceptions like Problem Writing java based JMS Client for WildFly10

       

      Any ideas what could be wrong with my configuration?

        • 1. Re: Problems connecting from standalone client to ActiveMQ Queue (migrating from wildfly 9 to 10)
          Justin Bertram Master

          You have a couple of choices here:

          1. Use the Artemis JNDI implementation which is different than the HornetQ JNDI implementation in that it is 100% client-side (i.e. no remote look-up is performed).
          2. Use the Wildfly JNDI implementation.

           

          Right now you're using a mix of both so it's not surprising that it wouldn't work.

           

          If you choose option #1 you'll need to configure your jndi.properties like so:

          java.naming.factory.initial=org.apache.activemq.artemis.jndi.ActiveMQInitialContextFactory

          connectionFactory.jms/RemoteConnectionFactory=tcp://wildfly:8111?httpUpgradeEnabled=true&consumerWindowSize=0&reconnectAttempts=-1&connectionTtl=-1

          queue.jms/xrunQueue=xrun

          topic.jms/xrunTopic=xrun

          topic.jms/Jobs=Jobs

          Then nothing in your code should need to change.  Note: in this scenario nothing is actually looked up on the server.  Everything is configured in the jndi.properties file.

           

          If you choose option #2 you'll need to configure your jndi.properties like so:

          java.naming.provider.url=http-remoting://wildfly:8111

          java.naming.factory.initial=org.jboss.naming.remote.client.InitialContextFactory

          java.naming.security.principal=JMS_USER 

          java.naming.security.credentials=JMS_PASSWORD 

          • 2. Re: Problems connecting from standalone client to ActiveMQ Queue (migrating from wildfly 9 to 10)
            Justin Bertram Master

            One more thing...

             

            I see your "jms/RemoteConnectionFactory" connection factory has a connection-ttl of "-1."  I would highly discourage this as any network issues which cause the client to lose its connection to the broker or if the client stops without properly closing its connection (e.g. if it crashes or is poorly written) then resources on the broker will leak since it won't be able to detect the dead connections and close them.