0 Replies Latest reply: Jun 24, 2010 1:08 PM by 807581 RSS

    JMSException on receive() for Expired Messages

    807581
      We are running 4.4u1 on Solaris with a producer-consumer model (many consumers).

      We are using the JMS expiration/TTL as part of the application logic to let messages expire before they are stale (and we have code that reloads the queue to keep data fresh).

      What we are seeing is that messages that have expired and been reaped are still being delivered to consumers and we get a JMSException from the receive():

      com.sun.messaging.jms.JMSException: [ACKNOWLEDGE_REPLY(25)] [C4036]: A broker error occurred. :[409] [B1261]: Transaction acknowledgement could not be added because message 27-17.228.107.46(bb:0:ac:54:fe:6f)-60503-1277323914099[[consumer:8324667956156934400, type=NONE]:[consumer:0, type=NONE]]TUID=8324667956156936704 has already been removed user=guest, broker=server1:7676(54311)
           at com.sun.messaging.jmq.jmsclient.ProtocolHandler.throwServerErrorException(ProtocolHandler.java:3982)
           at com.sun.messaging.jmq.jmsclient.ProtocolHandler.acknowledge(ProtocolHandler.java:2605)
           at com.sun.messaging.jmq.jmsclient.SessionImpl.doAcknowledge(SessionImpl.java:1382)
           at com.sun.messaging.jmq.jmsclient.SessionImpl.transactedAcknowledge(SessionImpl.java:1265)
           at com.sun.messaging.jmq.jmsclient.SessionImpl.acknowledge(SessionImpl.java:1128)
           at com.sun.messaging.jmq.jmsclient.MessageConsumerImpl.receive(MessageConsumerImpl.java:466)

      We believe what is happening is that the expired messages are still in the consumer buffer (see threads on consumerFlowLimit); so the message is expired and reaped; but the object is still in the consumer buffer and are trying to deliver to the consumer.

      If this community agrees with my root-cause; then I would propose two fixes: (1) the reaper should expire messages from the queue and any buffers; and (2) we should have a property to disable the consumer buffers (The buffers guarantee that messages will be delivered out-of-order when running with multiple consumers -- there is no way to get openMQ to round-robin in the correct sequence!)