2 Replies Latest reply on Feb 7, 2017 7:15 AM by Steve Hayes

    Sending JMS Messages From One WildFly instance to another

    Steve Hayes Newbie

      I'm currently involved in porting an application from JBoss 4.3.0 to WildFly 10.1.0.Final and need to send messages from
      one WildFly instance to a queue on another WildFly instance.

       

      It would seem that the client instance is sending the messages to itself rather than the destination. This seems odd as
      the same client instance can make remote EJB calls to the destination using similar code and the http connector.

       

      The client instance has the following in standalone-full.xml:

       

              <subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0">

                  <server name="default">

                      <security-setting name="#">

                          <role name="guest" send="true" consume="true" create-non-durable-queue="true" delete-non-durable-queue="true"/>

                      </security-setting>

                      <address-setting name="#" dead-letter-address="jms.queue.DLQ" expiry-address="jms.queue.ExpiryQueue" max-size-bytes="10485760" page-size-bytes="2097152" message-counter-history-day-limit="10"/>

                      <http-connector name="http-connector" socket-binding="http" endpoint="http-acceptor"/>

                      <http-connector name="http-connector-throughput" socket-binding="http" endpoint="http-acceptor-throughput">

                          <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"/>

                      <connection-factory name="InVmConnectionFactory" entries="java:/ConnectionFactory" connectors="in-vm"/>

                      <connection-factory name="RemoteConnectionFactory" entries="java:jboss/exported/jms/RemoteConnectionFactory" connectors="http-connector"/>

                      <pooled-connection-factory name="activemq-ra" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory" connectors="in-vm" transaction="xa"/>

                  </server>

              </subsystem>

       

      The destination instance has the following in standalone-full.xml:

       

              <subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0">

                  <server name="default">

                      <security domain="Interica"/>

                      <security-setting name="#">

                          <role name="EnigmaDeveloper" send="true" consume="true" create-non-durable-queue="true" delete-non-durable-queue="true"/>

                      </security-setting>

                      <address-setting name="#" dead-letter-address="jms.queue.DLQ" expiry-address="jms.queue.ExpiryQueue" max-size-bytes="10485760" page-size-bytes="2097152" message-counter-history-day-limit="10"/>

                      <http-connector name="http-connector" socket-binding="http" endpoint="http-acceptor"/>

                      <http-connector name="http-connector-throughput" socket-binding="http" endpoint="http-acceptor-throughput">

                          <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="LogStoreQueue" entries="jms/queue/LogStoreQueue java:jboss/exported/jms/queue/LogStoreQueue"/>

                      <jms-topic name="PARSLoggingTopic" entries="topic/PARSLoggingTopic"/>

                      <jms-topic name="ApplicationRenameTopic" entries="jms/topic/ApplicationRenameTopic"/>

                      <connection-factory name="InVmConnectionFactory" entries="java:/ConnectionFactory" connectors="in-vm"/>

                      <connection-factory name="RemoteConnectionFactory" entries="java:jboss/exported/jms/RemoteConnectionFactory" connectors="http-connector"/>

                      <pooled-connection-factory name="activemq-ra" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory" connectors="in-vm" transaction="xa"/>

                  </server>

              </subsystem>

       

      And this is the client code (I've tried with and without the bits that are commented out):

       

              Properties env = new Properties();

       

            env.put( Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory" );
           //env.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");
           //env.put("jboss.naming.client.ejb.context", true);

              env.put( "jboss.naming.client.connect.options.org.xnio.Options.SASL_POLICY_NOPLAINTEXT", "false" );

              env.put( "jboss.naming.client.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS", "false" );

              env.put(Context.PROVIDER_URL, "http-remoting://destination:8080);

             env.put( Context.SECURITY_PRINCIPAL, "username" );
             env.put( Context.SECURITY_CREDENTIALS, "password" );

             

              InitialContext ctx= new InitialContext(env);

              QueueConnectionFactory factory = (QueueConnectionFactory) ctx.lookup("jms/RemoteConnectionFactory");

              connection = factory.createQueueConnection("username","password");

              session =  connection.createQueueSession(false, Session.AUTO_ACKNOWLEDGE);

              queue = (Queue) ctx.lookup("jms/queue/LogStoreQueue");

              sender = session.createSender(queue);

       

       

      We start each instance with -b 0.0.0.0 and I've seen threads suggesting that this can cause issues, however I would have thought I would get the
      same issues with remote EJB calls as they use the same http connector.

       

      Any help would be much appreciated!!!

        • 1. Re: Sending JMS Messages From One WildFly instance to another
          Justin Bertram Master

          Couple of points/questions:

          1. Why not use an Artemis core bridge to move messages between instances?  It would require a few lines of configuration, no code, no deployments, etc., and it would likely be faster.
          2. Your code is doing a JNDI lookup for "jms/queue/LogStoreQueue".  This queue is only available on the "destination instance" (i.e. not on the "client instance").  Is this JNDI lookup succeeding?  If so, that indicates to me that the JNDI lookup is happening on the "destination instance" as intended.
          3. BTW, binding Wildfly to 0.0.0.0 presents problems for JMS clients as described in this thread (and many others). I'm not very experienced with EJBs so I'm not sure it suffers from the same problem, but since it's a rather different technology I imagine it doesn't.
          • 2. Re: Sending JMS Messages From One WildFly instance to another
            Steve Hayes Newbie

            Thanks for the suggestions. I was thinking about doing a bridge.

            As it turns out, this only happens on my test system at the moment. No one else appears to be getting the issue.

            I'm assuming it's a network config / binding to 0.0.0.0 issue.

            I haven't got to the bottom of the problem but due to time constraints I'm going to leave it for now.

             

            Thanks

             

            Steve