Uploaded image for project: 'JBoss Enterprise Application Platform 4 and 5'
  1. JBoss Enterprise Application Platform 4 and 5
  2. JBPAPP-5537

Change the defaults to useDLQ=false for JBoss Messaging

    XMLWordPrintable

Details

    • Documentation (Ref Guide, User Guide, etc.), Release Notes, Compatibility/Configuration
    • Workaround Exists
    • Hide

      set useDLQ to false on the MDB

      Show
      set useDLQ to false on the MDB
    • Hide
      If a message-driven bean is deployed with the default settings (useDLQ=true, DLQMaxResent=5) and message redelivery is prompted, a message remains in the queue in a "delivering" state even after the message is delivered to the dead letter queue. The workaround for this issue is to disable the dead letter queue handling on the MDB side by setting useDLQ=false.
      Show
      If a message-driven bean is deployed with the default settings (useDLQ=true, DLQMaxResent=5) and message redelivery is prompted, a message remains in the queue in a "delivering" state even after the message is delivered to the dead letter queue. The workaround for this issue is to disable the dead letter queue handling on the MDB side by setting useDLQ=false.
    • Documented as Known Issue

    Description

      If you deploy a MDB with default setting (useDLQ=true, DLQMaxResent=5) and cause message redelivery , messages will stay as "delivering" state in the queue even after the message is delivered to DLQ. You can observe it through jmx-console (MessageCount, DeliveringCount).
      In case that you use Ordering Group message introduced from JBM 1.4.0.SP3.CP08/1.4.4.GA, subsequent messages will be stuck in the queue and won't be processed.

      I attached reproducer.zip

      • unzip attached reproducer.zip
      • modify {jboss.home}

        in build.xml

      • ant dist
      • ant deploy
      • ant run
      • check MessageCount and DeliveringCount of queue/A with jmx-console
      • ant run
      • check console(or server.log) that the second message is not recieved

      According to Adrian's comment on JBAS-7465:
      ====
      However, if the jms product already supports DLQ processing then you should disable
      the DLQ processing in the MDB. i.e. useDLQ=false.

      It is duplicate work and not as "reliable" as the jms product handling internally, e.g.
      if the jms connection breaks between sending the message to the DLQ and ACKing the
      dead message, you'll eventually end up with the message twice in the DLQ.

      The feature only exists because JBossMQ did not have internal DLQ processing.
      ====

      The defaults should be "useDLQ=false" for JBoss Messaging and in its document encourage users to use JBM settings instead.

      Attachments

        Issue Links

          is cloned by

          Bug - A problem that impairs or prevents the functions of the product. JBPAPP-3352 Change the defaults to useDLQ=false for JBoss Messaging

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Resolved
          is related to

          Feature Request - Feature requests from customers and/or users JBAS-7601 Change the defaults to useDLQ=false for JBoss Messaging

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Closed
          relates to

          Bug - A problem that impairs or prevents the functions of the product. JBAS-7465 Some issues with JCA's DLQ handling

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Closed

          Activity

            People

              gaohoward Howard Gao
              rhn-support-tkobayas Toshiya Kobayashi
              Russell Dickenson Russell Dickenson (Inactive)
              Votes:
              1 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: