glassfish
  1. glassfish
  2. GLASSFISH-6617

Ignoring MDB's activation-spec for RedeliveryInterval and RedeliveryAttempts

    Details

    • Issuezilla Id:
      6,617

      Description

      I set these parameters using activation-config within sun specific descriptor.
      It's ignored in runtime.

      Futhermore, documentation contains information that these parameters affect on
      container's behaviour in case of throw RuntimeException from onMessage method.
      What about MessageDrivenContext.setRollbackOnly() method's invoke ? Does
      container should treat it in another way?

      I tried both ways, and found:
      1) in case of using setRollbackOnly() - message is redelivered with no limit
      2) in case of throwing RuntimeException - message is redelivered once, and dump
      to the default dead-message-queue

      regards
      Beniamin

        Activity

        Hide
        David Zhao added a comment -

        JMSRA should take care of setting imq.transaction.message.maxConsecutiveRollbacks property to MQ.

        Show
        David Zhao added a comment - JMSRA should take care of setting imq.transaction.message.maxConsecutiveRollbacks property to MQ.
        Hide
        David Zhao added a comment -

        This defect has been fixed by a new MQ 5.0 property "imq.transaction.message.maxConsecutiveRollbacks".

        For the EMBEDDED/LOCAL jms service of glassfish, the property can be set via admin gui:

        Configurations -> server-config -> Java Message Service -> Additional Properties

        For the REMOTE jms service of glassfish, the property should be set in the remote broker's config properties file.

        Please refer to the MQ-139 for the value of the property:

        If <= 0, this feature is disabled;
        If > 0, for running in GlassFish with JMSRA, when consecutive rollback a message to a consumer exceeds this number, the broker will automatically put this message to DMQ (if there are more than 1 message in the transaction, only the last message in the transaction is put to DMQ) and and rollback the rest of the transaction then return an error status to rollback

        Show
        David Zhao added a comment - This defect has been fixed by a new MQ 5.0 property "imq.transaction.message.maxConsecutiveRollbacks". For the EMBEDDED/LOCAL jms service of glassfish, the property can be set via admin gui: Configurations -> server-config -> Java Message Service -> Additional Properties For the REMOTE jms service of glassfish, the property should be set in the remote broker's config properties file. Please refer to the MQ-139 for the value of the property: If <= 0, this feature is disabled; If > 0, for running in GlassFish with JMSRA, when consecutive rollback a message to a consumer exceeds this number, the broker will automatically put this message to DMQ (if there are more than 1 message in the transaction, only the last message in the transaction is put to DMQ) and and rollback the rest of the transaction then return an error status to rollback
        Hide
        gfuser9999 added a comment -

        The fix by MQ-139 is not really useful and does not address the issue.
        In fact if you see for the "Exception" trigger retry
        you have endpointExceptionRedeliveryInterval,
        endpointExceptionRedeliveryAttempts
        The retry in the JMSRA to have a delay for redelivery help
        in transient failures (in time for say some recovery)

        1) In the MQ broker fix case, i believe if one rollback, the message
        will come back almost immediately and then within 1 min
        it is possible hundred or thousands retry count is made
        and it goes to DMQ (or drop)

        2) Furthermore i do not think a global MQ broker switch caters
        to different client and destination that requires their
        own retry mechanism.

        I do hope you can reconsider this fix as IT is surely INCOMPLETE
        and does not really work that well. (So i do not think
        you can say it 100% fix... It is not .....

        Show
        gfuser9999 added a comment - The fix by MQ-139 is not really useful and does not address the issue. In fact if you see for the "Exception" trigger retry you have endpointExceptionRedeliveryInterval, endpointExceptionRedeliveryAttempts The retry in the JMSRA to have a delay for redelivery help in transient failures (in time for say some recovery) 1) In the MQ broker fix case, i believe if one rollback, the message will come back almost immediately and then within 1 min it is possible hundred or thousands retry count is made and it goes to DMQ (or drop) 2) Furthermore i do not think a global MQ broker switch caters to different client and destination that requires their own retry mechanism. I do hope you can reconsider this fix as IT is surely INCOMPLETE and does not really work that well. (So i do not think you can say it 100% fix... It is not .....
        Hide
        David Zhao added a comment -

        gfuser9999,

        Thanks your feedback!

        This defect is to fix the infinite msg resending caused by setRollbackOnly(). So I think it is OK to close it by introducing the global property.

        Your suggestion is reasonable to be a potential enhancement which needs to be addressed at jms spec level. Please discuss it here if you think it is a general requirement which may help jms users on that.

        Show
        David Zhao added a comment - gfuser9999, Thanks your feedback! This defect is to fix the infinite msg resending caused by setRollbackOnly(). So I think it is OK to close it by introducing the global property. Your suggestion is reasonable to be a potential enhancement which needs to be addressed at jms spec level. Please discuss it here if you think it is a general requirement which may help jms users on that.
        Hide
        amyk added a comment -

        MQ-220 has been filed to track JMS specification (and any other relevant Java EE specification) and corresponding JMSRA/MQ/GlassFish changes in order to support the improvements asked by gfuser9999

        Show
        amyk added a comment - MQ-220 has been filed to track JMS specification (and any other relevant Java EE specification) and corresponding JMSRA/MQ/GlassFish changes in order to support the improvements asked by gfuser9999

          People

          • Assignee:
            David Zhao
            Reporter:
            beniamin
          • Votes:
            3 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: