7 Replies Latest reply on Nov 10, 2014 1:03 PM by Justin Bertram

    Wildfly 8.1: Can't connect remote to JMS-Topic using @MessageDriven

    Dee Kay Newbie

      Hi all,

       

      i'm running a wildfly 8.1 cluster and can't connect remotely to my JMS-Topic with @MessageDriven.

      It all works fine doing it manually (trough JNDI-lookup), but fails if i try it by an @MessageDriven:activationConfig.

       

       

      JMS-Config (Server, bound to http-connector):

       

      <jms-destinations>

           .....

           <jms-topic name="byzzyTopic">

                <entry name="java:/jms/topic/byzzy"/>

                <entry name="java:jboss/exported/topic/byzzy"/>

           </jms-topic>

      </jms-destinations>

       

       

      Successfully call from remote-client (Wildfly running on another JVM on the same host):

       

            final Properties env = new Properties();

           env.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory");

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

           env.put(Context.SECURITY_PRINCIPAL, "user");

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

           Context remoteContext;

           try {

               remoteContext = new InitialContext(env);

               ConnectionFactory factory = (ConnectionFactory) remoteContext.lookup("jms/RemoteConnectionFactory");

               HornetQTopic topic = (HornetQTopic) remoteContext.lookup("topic/byzzy");

               System.out.println(topic.getTopicName());

               System.out.println(topic.getAddress());

           } catch (NamingException exception) {

               exception.printStackTrace();

           }

       

       

       

      Failing call from remote-client using @MessageDriven-annotation (Wildfly running on another JVM on the same host):

       

      @MessageDriven(

          activationConfig = {

              @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Topic"),

              @ActivationConfigProperty(propertyName = "destination", propertyValue = "topic/byzzy"),

              @ActivationConfigProperty(propertyName = "user", propertyValue = "user"),

              @ActivationConfigProperty(propertyName = "password", propertyValue = "password"),

              @ActivationConfigProperty(propertyName="connectorClassName", propertyValue = "org.hornetq.core.remoting.impl.netty.NettyConnectorFactory"),

              @ActivationConfigProperty(propertyName="connectionParameters", propertyValue = "http-remoting://127.0.0.1:8080"),

              @ActivationConfigProperty(propertyName = "reconnectAttempts", propertyValue = "-1"),

              @ActivationConfigProperty(propertyName = "setupAttempts", propertyValue = "-1") })

      public class BackendListener implements MessageListener {

      ...

      }

       

      Using this annotation i get the following output om startup:

       

      14:32:07,177 INFO  [org.jboss.as.ejb3] (MSC service thread 1-10) JBAS014142: Started message driven bean 'BackendListener' with 'hornetq-ra.rar' resource adapter

      14:32:08,456 INFO  [org.jboss.resteasy.plugins.validation.AbstractValidatorContextResolver] (MSC service thread 1-15) Unable to find CDI supporting ValidatorFactory. Using default ValidatorFactory

      14:32:08,826 DEBUG [org.hornetq.ra] (default-threads - 1) Setting up org.hornetq.ra.inflow.HornetQActivationSpec(ra=org.hornetq.ra.HornetQResourceAdapter@7852b725 destination=topic/byzzy destinationType=javax.jms.Topic ack=Auto-acknowledge durable=false clientID=null user=null maxSession=15)

      14:32:08,826 DEBUG [org.hornetq.ra] (default-threads - 1) No connector params provided using default

      14:32:08,826 DEBUG [org.hornetq.ra] (default-threads - 1) Creating Connection Factory on the resource adapter for transport=[TransportConfiguration(name=78e8c65d-6682-11e4-8464-b931d8592433, factory=org-hornetq-core-remoting-impl-netty-NettyConnectorFactory) ] with ha=false

      14:32:08,826 DEBUG [org.hornetq.ra] (default-threads - 1) Using context {java.naming.ldap.version=3, java.naming.factory.url.pkgs=org.jboss.as.naming.interfaces:org.jboss.ejb.client.naming} for org.hornetq.ra.inflow.HornetQActivationSpec(ra=org.hornetq.ra.HornetQResourceAdapter@7852b725 destination=topic/byzzy destinationType=javax.jms.Topic ack=Auto-acknowledge durable=false clientID=null user=null maxSession=15)

      14:32:08,826 DEBUG [org.hornetq.ra] (default-threads - 1) Destination type defined as javax.jms.Topic

      14:32:08,826 DEBUG [org.hornetq.ra] (default-threads - 1) Retrieving javax.jms.Topic "topic/byzzy" from JNDI

      14:32:08,842 DEBUG [org.hornetq.ra] (default-threads - 1) Unable to retrieve topic/byzzy from JNDI. Creating a new javax.jms.Topic named byzzy to be used by the MDB.

       

       

      What's wrong with my @MessageDriven-Annotation?

      Any ideas?

       

      Thanks in advance

       

      Daniel

        • 1. Re: Wildfly 8.1: Can't connect remote to JMS-Topic using @MessageDriven
          Justin Bertram Master

          You're configuring your MDB incorrectly.  Try using this instead:

           

          @ActivationConfigProperty(propertyName="connectionParameters", propertyValue = "host=127.0.0.1;port=8080")
          

           

          HornetQ doesn't use the http-remoting protocol to communicate between client and server.  That is used by the client-side JNDI implementation.

          • 2. Re: Wildfly 8.1: Can't connect remote to JMS-Topic using @MessageDriven
            Dee Kay Newbie

            Doen't help. Exactly the same behaviour....

            • 3. Re: Wildfly 8.1: Can't connect remote to JMS-Topic using @MessageDriven
              Justin Bertram Master

              Setting aside the DEBUG message, does your MDB receive messages sent to the topic?

              • 4. Re: Wildfly 8.1: Can't connect remote to JMS-Topic using @MessageDriven
                Dee Kay Newbie

                No. The server is sending messages to this topic all 5 s. But how could it receive messages without a connection?

                • 5. Re: Re: Wildfly 8.1: Can't connect remote to JMS-Topic using @MessageDriven
                  Justin Bertram Master

                  I think you're misinterpreting the DEBUG message, "Unable to retrieve topic/byzzy from JNDI. Creating a new javax.jms.Topic named byzzy to be used by the MDB."  All this message is saying is that the HornetQ JCA RA couldn't retrieve "topic/byzzy" from JNDI and therefore will instantiate a topic named "byzzy".  However, it's not surprising that the HornetQ JCA RA couldn't retrieve "topic/byzzy" from JNDI because that topic is defined in JNDI on a remote server and you haven't told the HornetQ JCA RA how to connect to JNDI on any remote server so it defaults to local JNDI which, of course, doesn't have the topic in question. 


                  Remember, JNDI and JMS are 100% independent specifications so telling the HornetQ JCA RA how to connect to the remote HornetQ JMS implementation (e.g. via the "connectorClassName" and "connectionParameters" activation configuration properties) is not the same as telling it how to connect to the remote JNDI server (e.g. via the "jndiParams" activation configuration property).


                  You'll note that the topic the HornetQ JCA RA decides to instantiate is named "byzzy" which doesn't match the actual name of the topic as it's defined on the remote server (i.e. "byzzyTopic").  I didn't notice this before so you'll need to make further adjustments to your MDB config to make things work properly.  Here's what I recommend you add/change in the MDB config you pasted previously:

                   

                  @ActivationConfigProperty(propertyName="destination", propertyValue = "byzzyTopic"),
                  @ActivationConfigProperty(propertyName="connectionParameters", propertyValue = "host=127.0.0.1;port=8080"),
                  @ActivationConfigProperty(propertyName="useJNDI", propertyValue = "false") 
                  
                  1 of 1 people found this helpful
                  • 6. Re: Re: Re: Wildfly 8.1: Can't connect remote to JMS-Topic using @MessageDriven
                    Dee Kay Newbie

                    Thanks, I can now see that HornetQ is succesfully connecting to my server:

                     

                    16:25:56,327 DEBUG [org.hornetq.ra] (default-threads - 1) Setting up org.hornetq.ra.inflow.HornetQActivationSpec(ra=org.hornetq.ra.HornetQResourceAdapter@88c04e5 destination=byzzyTopic destinationType=javax.jms.Topic ack=Auto-acknowledge durable=false clientID=null user=dkohl password=**** maxSession=15)

                    16:25:56,328 DEBUG [org.hornetq.ra] (default-threads - 1) Creating Connection Factory on the resource adapter for transport=[TransportConfiguration(name=88d4a6d3-675b-11e4-a810-d34b7ae59e48, factory=org-hornetq-core-remoting-impl-netty-NettyConnectorFactory) ?port=8080&host=127-0-0-1] with ha=false

                    16:25:56,328 INFO  [org.hornetq.ra] (default-threads - 1) HQ151004: Instantiating javax.jms.Topic "byzzyTopic" directly since UseJNDI=false.

                    16:25:56,329 DEBUG [org.hornetq.core.client] (default-threads - 1) Trying reconnection attempt 0/1

                    16:25:56,332 DEBUG [org.hornetq.core.client] (default-threads - 1) Trying to connect with connector = org.hornetq.core.remoting.impl.netty.NettyConnectorFactory@48a7f2bb, parameters = {port=8080, host=127.0.0.1} connector = NettyConnector [host=127.0.0.1, port=8080, httpEnabled=false, httpUpgradeEnabled=false, useServlet=false, servletPath=/messaging/HornetQServlet, sslEnabled=false, useNio=true]

                    16:25:56,352 DEBUG [org.hornetq.core.client] (default-threads - 1) Started Netty Connector version unknown

                    16:25:56,352 DEBUG [org.hornetq.core.client] (default-threads - 1) Trying to connect at the main server using connector :TransportConfiguration(name=88d4a6d3-675b-11e4-a810-d34b7ae59e48, factory=org-hornetq-core-remoting-impl-netty-NettyConnectorFactory) ?port=8080&host=127-0-0-1

                    16:25:56,353 DEBUG [org.hornetq.core.client] (default-threads - 1) Remote destination: /127.0.0.1:8080

                    16:25:56,402 DEBUG [org.hornetq.core.client] (default-threads - 1) Reconnection successful

                     

                     

                    But i still get no messages. Later on i get this message:

                     

                    16:31:28,402 WARN  [org.hornetq.core.client] (Thread-0 (HornetQ-client-global-threads-548402305)) HQ212037: Connection failure has been detected: HQ119011: Did not receive data from server for org.hornetq.core.remoting.impl.netty.NettyConnection@1e2b1ce7[local= 0.0.0.0/0.0.0.0:61994, remote=null] [code=CONNECTION_TIMEDOUT]

                     

                    I am a little bit confused about the Connection-information (in red).....

                     

                     

                     

                    My server is sending messages each 5s....

                     

                    16:34:57,228 INFO  [stdout] (EJB default - 5) Sending message to topic<HornetQTopic[byzzyTopic]> message<HornetQMessage[null]:PERSISTENT>

                     

                     

                     

                    ......and I implemented the following fragment on the client to check if the messages are sent, and indeed i get them:

                     

                            final Properties env = new Properties();

                            env.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory");

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

                            env.put(Context.SECURITY_PRINCIPAL, "user");

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

                            Context remoteContext;

                            try {

                                remoteContext = new InitialContext(env);

                                factory = (TopicConnectionFactory) remoteContext.lookup("jms/RemoteConnectionFactory");

                                topicConnection = (TopicConnection) factory.createTopicConnection("user", "password");

                                topicSession = topicConnection.createTopicSession(false, Session.AUTO_ACKNOWLEDGE);

                                topic = (Topic)remoteContext.lookup("topic/byzzy");

                                topicReceiver = topicSession.createSubscriber(topic);

                                topicReceiver.setMessageListener(this);

                                topicConnection.start();

                            } catch (NamingException | JMSException exception) {

                                exception.printStackTrace();

                            }

                     

                     

                     

                    My client is able to receive this messages using the classic way, but what am i still missing in my @MessageDriven ??

                     

                     

                     

                    Thanks for your help

                     

                    Daniel

                    • 7. Re: Re: Re: Wildfly 8.1: Can't connect remote to JMS-Topic using @MessageDriven
                      Justin Bertram Master

                      But i still get no messages. Later on i get this message:

                       

                      16:31:28,402 WARN  [org.hornetq.core.client] (Thread-0 (HornetQ-client-global-threads-548402305)) HQ212037: Connection failure has been detected: HQ119011: Did not receive data from server for org.hornetq.core.remoting.impl.netty.NettyConnection@1e2b1ce7[local= 0.0.0.0/0.0.0.0:61994, remote=null] [code=CONNECTION_TIMEDOUT]

                       

                      I am a little bit confused about the Connection-information (in red).....

                      The "local" and "remote" values there are generated by calling localAddress() and remoteAddress() respectively on the underlying io.netty.channel.Channel.  I believe the "remote" value is null because the channel is no longer connected because it timed out.  The underlying cause of the connection timeout may hold the key to your MDB's problem.  Could you provide me with a reproducible test-case?  If I can't reproduce it with your test case then it points to an environmental issue.  If I can then it points to something else, either code or configuration.