1 Reply Latest reply on May 5, 2011 3:54 AM by Michael Justin

    JBoss 6 stacktrace "removing consumer which did not handle a message"

    Michael Justin Novice

      Hello,

       

      In a simple JavaServer Faces application, I get this stacktrace in AS 6.0.0.Final for every time the code uses receiveNoWait:

       

      08:45:13,819 WARN  [org.hornetq.core.server.impl.QueueImpl] removing consumer which did not handle a message, consumer=org.hornetq.core.server.impl.ServerConsumerImpl@119087d, message=Reference[4294968866]:NON-RELIABLE: java.lang.IndexOutOfBoundsException
          at org.jboss.netty.buffer.AbstractChannelBuffer.setIndex(AbstractChannelBuffer.java:67) [:6.0.0.Final]
          at org.hornetq.core.buffers.impl.ChannelBufferWrapper.setIndex(ChannelBufferWrapper.java:497) [:6.0.0.Final]
          at org.hornetq.core.message.impl.MessageImpl.forceCopy(MessageImpl.java:941) [:6.0.0.Final]
          at org.hornetq.core.message.impl.MessageImpl.encodeToBuffer(MessageImpl.java:872) [:6.0.0.Final]
          at org.hornetq.core.message.impl.MessageImpl.getEncodedBuffer(MessageImpl.java:470) [:6.0.0.Final]
          at org.hornetq.core.protocol.core.impl.wireformat.SessionReceiveMessage.encode(SessionReceiveMessage.java:73) [:6.0.0.Final]
          at org.hornetq.core.protocol.core.impl.ChannelImpl.send(ChannelImpl.java:163) [:6.0.0.Final]
          at org.hornetq.core.protocol.core.impl.ChannelImpl.sendBatched(ChannelImpl.java:147) [:6.0.0.Final]
          at org.hornetq.core.protocol.core.impl.CoreSessionCallback.sendMessage(CoreSessionCallback.java:75) [:6.0.0.Final]
          at org.hornetq.core.server.impl.ServerConsumerImpl.deliverStandardMessage(ServerConsumerImpl.java:644) [:6.0.0.Final]
          at org.hornetq.core.server.impl.ServerConsumerImpl.handle(ServerConsumerImpl.java:253) [:6.0.0.Final]
          at org.hornetq.core.server.impl.QueueImpl.handle(QueueImpl.java:1384) [:6.0.0.Final]
          at org.hornetq.core.server.impl.QueueImpl.deliver(QueueImpl.java:1175) [:6.0.0.Final]
          at org.hornetq.core.server.impl.QueueImpl.access$700(QueueImpl.java:67) [:6.0.0.Final]
          at org.hornetq.core.server.impl.QueueImpl$DeliverRunner.run(QueueImpl.java:1601) [:6.0.0.Final]
          at org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:100) [:6.0.0.Final]
          at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) [:1.6.0_19]
          at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [:1.6.0_19]
          at java.lang.Thread.run(Unknown Source) [:1.6.0_19]
      

       

      here is the code for the JSF ManagedBean:

       

      package demo;
      
      import java.util.logging.*;
      import javax.annotation.Resource;
      import javax.faces.bean.ManagedBean;
      import javax.jms.*;
      
      @ManagedBean
      public class Bean {
          @Resource(mappedName = "java:/ConnectionFactory")
          private ConnectionFactory connectionFactory;
          @Resource(mappedName = "/queue/TOOL.DEFAULT")
          private Queue queue;
      
          public String getMessage() {
              String result = "no message";
              try {
                  Connection connection = connectionFactory.createConnection();
                  connection.start();
                  Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
                  MessageConsumer consumer = session.createConsumer(queue);
                  Message message = consumer.receiveNoWait();
                  if (message != null) {
                      if (message instanceof BytesMessage) {
                      result = "bytes - " + ((BytesMessage) message).getBodyLength();
                      }
                  }
                  connection.close();
              } catch (JMSException ex) {
                  Logger.getLogger(Bean.class.getName()).log(Level.SEVERE, null, ex);
              }
              return result;
          }
      }
      

       

      I am not sure what this warningn and the NON-RELIABLE: java.lang.IndexOutOfBoundsException means in this context.

      The code works as expected, only the log looks like there is a problem somewhere.

      Should this be entered in the issue tracker?

       

      Regards,

      Michael Justin