5 Replies Latest reply on Jun 29, 2011 4:42 AM by dimitri_hautot

    Connecting over netty to standalone hq server

    tavgm

      Hi,

       

      im  using hornetq in standalone  non-cluster mode. While connecting with mule over netty to the local hq  server i got following exceptions.

      If someone has an hint for me,  that would pretty cool. Configuration files for hq server are not  edited.

       

      Thanks

       

       

      java   -XX:+UseParallelGC -XX:+AggressiveOpts -XX:+UseFastAccessorMethods  -Xms512M -Xmx1024M  -Dhornetq.config.dir=../config/stand-alone/non-clustered  -Djava.util.logging.config.file=../config/stand-alone/non-clustered/logging.properties   -Djava.library.path=. -classpath  ../lib/netty.jar:../lib/jnpserver.jar:../lib/jnp-client.jar:../lib/jboss-mc.jar:../lib/jboss-jms-api.jar:../lib/hornetq-logging.jar:../lib/hornetq-jms.jar:../lib/hornetq-jms-client.jar:../lib/hornetq-jboss-as-integration.jar:../lib/hornetq-core.jar:../lib/hornetq-core-client.jar:../lib/hornetq-bootstrap.jar:../config/stand-alone/non-clustered:../schemas/   org.hornetq.integration.bootstrap.HornetQBootstrapServer  hornetq-beans.xml
      ***********************************************************************************
      [main]   15:40:41,724 INFO  [org.hornetq.integration.bootstrap.HornetQBootstrapServer]   Starting  HornetQ Server
      [main] 15:40:42,530 WARNING  [org.hornetq.core.deployers.impl.FileConfigurationParser]  AIO  wasn't  located on this platform, it will fall back to using pure Java NIO. If  your platform is Linux, install LibAIO to enable the AIO journal
      [main]   15:40:42,581 INFO [org.hornetq.core.server.impl.HornetQServerImpl]    live server is starting..
      [main] 15:40:42,612 INFO  [org.hornetq.core.persistence.impl.journal.JournalStorageManager]   Using  NIO Journal
      [main] 15:40:42,633 WARNING  [org.hornetq.core.server.impl.HornetQServerImpl]  Security risk! It  has  been detected that the cluster admin user and password have not been  changed from the installation default. Please see the HornetQ user  guide, cluster chapter, for instructions on how to do this.
      [main]  15:40:44,000 INFO [org.hornetq.core.remoting.impl.netty.NettyAcceptor]    Started Netty Acceptor version 3.2.0.Final-r2292 localhost:5455 for CORE  protocol
      [main] 15:40:44,001 INFO  [org.hornetq.core.remoting.impl.netty.NettyAcceptor]  Started Netty   Acceptor version 3.2.0.Final-r2292 localhost:5445 for CORE protocol
      [main]   15:40:44,003 INFO [org.hornetq.core.server.impl.HornetQServerImpl]    HornetQ Server version 2.1.0.Final (marimbondo, 118) started
      [Old I/O  server worker (parentId: 21335499, channelId: 4301103, null =>  localhost/127.0.0.1:5445)]  15:40:52,293 SEVERE  [org.hornetq.core.protocol.core.impl.RemotingConnectionImpl]   Failed to  decode
      java.lang.IndexOutOfBoundsException
          at  org.jboss.netty.buffer.AbstractChannelBuffer.readByte(AbstractChannelBuffer.java:236)
            at  org.hornetq.core.buffers.impl.ChannelBufferWrapper.readNullableString(ChannelBufferWrapper.java:64)
            at  org.hornetq.core.protocol.core.impl.wireformat.CreateSessionMessage.decodeRest(CreateSessionMessage.java:192)
            at  org.hornetq.core.protocol.core.impl.PacketImpl.decode(PacketImpl.java:235)
            at  org.hornetq.core.protocol.core.impl.PacketDecoder.decode(PacketDecoder.java:495)
            at  org.hornetq.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:379)
            at  org.hornetq.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:459)
            at  org.hornetq.core.remoting.impl.netty.HornetQChannelHandler.messageReceived(HornetQChannelHandler.java:67)
            at  org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:100)
            at  org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:545)
            at  org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:754)
            at  org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:287)
            at  org.hornetq.core.remoting.impl.netty.HornetQFrameDecoder2.decode(HornetQFrameDecoder2.java:169)
            at  org.hornetq.core.remoting.impl.netty.HornetQFrameDecoder2.messageReceived(HornetQFrameDecoder2.java:134)
            at  org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:80)
            at  org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:545)
            at  org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:540)
            at  org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:274)
            at  org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:261)
            at org.jboss.netty.channel.socket.oio.OioWorker.run(OioWorker.java:90)
            at  org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108)
            at  org.jboss.netty.util.internal.IoWorkerRunnable.run(IoWorkerRunnable.java:46)
            at  org.jboss.netty.util.VirtualExecutorService$ChildExecutorRunnable.run(VirtualExecutorService.java:181)
            at  java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
            at  java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
            at java.lang.Thread.run(Thread.java:619)
      
      

      ** In addition*

      On client side i got this exception:

      Root Exception was: Timed out waiting for response when sending packet 30. Type: class org.hornetq.api.core.HornetQException

       

        • 1. Re: Connecting over netty to standalone hq server
          dimitri_hautot

          Hello,

           

          We faced the very same issue/stack trace. We were able to discover the reason causing the error.

           

          We just upgraded HornetQ from 2.0.0.GA to 2.2.2.Final. We only use JMS on HornetQ. All the clients run the client libraries version 2.2.2.Final, excepted one that was still running client libraries 2.0.0.GA. It is a webapp consuming messages on a JMS topic.

          The connexion is managed by Spring's http://static.springsource.org/spring/docs/2.5.6/api/org/springframework/jms/listener/DefaultMessageListenerContainer.html

           

          Each time this client poll the HornetQ server (standalone, non-clustered), we had this stack trace:

          Jun 27, 2011 1:07:50 PM org.hornetq.core.logging.impl.JULLogDelegate error

          SEVERE: Failed to decode

          java.lang.IndexOutOfBoundsException

                    at org.jboss.netty.buffer.AbstractChannelBuffer.readByte(AbstractChannelBuffer.java:236)

                    at org.hornetq.core.buffers.impl.ChannelBufferWrapper.readNullableString(ChannelBufferWrapper.java:64)

                    at org.hornetq.core.protocol.core.impl.wireformat.CreateSessionMessage.decodeRest(CreateSessionMessage.java:19

                  [...]

           

          We were also monitoring the HornetQ server with VisualVM, and we discovered that each time this exception was thrown, an additional thread was created in the HornetQ server, and was never cleared.

          • 2. Re: Connecting over netty to standalone hq server
            clebert.suconic

            you have to update your client libraries as well.

             

             

            If you are jumping to 2.2.2, go to 2.2.5 directly (it's better with a few bug fixes).

            • 3. Re: Connecting over netty to standalone hq server
              clebert.suconic

              BTW 2.2.2 -> 2.2.5 is acceptable. (better still to upgrade to 2.2.5 as there is maybe 1 or 2 bug fixes on client libraries)

               

              2.0.0 -> 2.2.5 (it doesn't work)

              • 4. Re: Connecting over netty to standalone hq server
                dimitri_hautot

                Hello Clebert,

                 

                Thanks for your comments.

                I'll plan upgrade to 2.2.5.

                 

                However, I thought about it again this morning, and I would like to share it with you.

                 

                There are cases where a message broker is the central middleware between applications from different departments, and you don't always have control on all of them.

                If a client application doesn't upgrade their client libraries at the same time you upgrade the broker, there are mainly two consequences:

                1) they can't produce/consume messages anymore; the problem is on their side

                2) if for each polling they increase the number of threads of the message broker you are in charge of, the problem is on your side

                 

                I understand HornetQ can't manage messages produced with an older version. However, I believe the broker should degrade gracefully.

                 

                 

                I'll upgrade to 2.2.5 on my laptop right now and see if things get better regarding the outlined problem.

                • 5. Re: Connecting over netty to standalone hq server
                  dimitri_hautot

                  Hello again,

                   

                  Good news: with version 2.2.5.Final, the broker detects connection attempts with incompatible versions and logs it. The thread count doesn't increase anymore (=degrade gracefully).

                  Also, on the client side, a similar message is logged.

                   

                  Nice tool, thank you!