Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.1
    • Fix Version/s: None
    • Labels:
      None

      Description

      This issue was raised on the JMS forum:
      https://forums.oracle.com/forums/thread.jspa?threadID=2124413
      and is being logged here on behalf of that contributor

      Poison messages are messages that are redelivered again and again when an untreated error occurs, possibly resulting in CPU eating long lasting loops.

      This is a well known messaging related issue, but it is not fully adressed by the JMS specification. The Message:getJMSRedelivered method can tell if a message is being redelivered. But this is not good enough and application servers implement their own solutions. Such solutions are based, for example, on redelivery limit and error destinations.

      With WebSphere 6, it is possible to specify, at the SI Bus destination level, an exception destination and a maximum failed deliveries threshold. When messages consumption fails more than the threshold allows, messages are moved to the exception destination.

      JBoss 4 has equivalent features, with a dead letter queue where messages that reached the redelivery limit are moved. It is also possible to use the specific 'JMS_JBOSS_REDELIVERY_DELAY' message property to specify a redelivery delay from the message producer side. JBoss 5 has the same features with the 'dead-letter-address', 'max-delivery-attempts' and 'redelivery-delay' destination configuration parameters.

      WebLogic has equivalent features, see 'Error Destination', 'Redelivery Limit' and 'Redelivery Delay' parameters.

      A portable mechanism should be defined.

        Activity

        Hide
        Nigel Deakin added a comment -

        JMS_SPEC-42 (already included in the JMS 2.0 Early Draft) makes support for JMSXDeliveryCount mandatory, which should make it easier for applications and frameworks to do their own poison message handling. However this does not itself define how poison messages are handled.

        I will raise this with the expert group for possible inclusion in the JMS 2.0 Public Draft. Tagging accordingly.

        Show
        Nigel Deakin added a comment - JMS_SPEC-42 (already included in the JMS 2.0 Early Draft) makes support for JMSXDeliveryCount mandatory, which should make it easier for applications and frameworks to do their own poison message handling. However this does not itself define how poison messages are handled. I will raise this with the expert group for possible inclusion in the JMS 2.0 Public Draft. Tagging accordingly.

          People

          • Assignee:
            Unassigned
            Reporter:
            Nigel Deakin
          • Votes:
            2 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated: