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
        beniamin added a comment -

        Nobody is interested in it.

        Show
        beniamin added a comment - Nobody is interested in it.
        Hide
        sanandal added a comment -

        "Reclassifying as P4 because this issue is not deemed "must fix" for this v2.1
        release whose primary release driver is SailFin.
        This issue will be scrubbed after this release and will be given the right
        priority for the next release."

        Show
        sanandal added a comment - "Reclassifying as P4 because this issue is not deemed "must fix" for this v2.1 release whose primary release driver is SailFin. This issue will be scrubbed after this release and will be given the right priority for the next release."
        Hide
        stenlee added a comment -
            • Issue 6617 has been confirmed by votes. ***
        Show
        stenlee added a comment - Issue 6617 has been confirmed by votes. ***
        Hide
        stenlee added a comment -

        i think this is "must have" for messaging. Loosing option to change this
        properties can be stopper for lot of usecases

        Show
        stenlee added a comment - i think this is "must have" for messaging. Loosing option to change this properties can be stopper for lot of usecases
        Hide
        beniamin added a comment -

        Not only "can be". It is actually the stopper for some cases.

        Show
        beniamin added a comment - Not only "can be". It is actually the stopper for some cases.
        Hide
        David Zhao added a comment -

        @Nigel http://www.java.net/forum/topic/glassfish/glassfish/jms-redelivery-interval-gf-21?force=231
        ===============================================

        If a MDB throws an exception then Glassfish (actually the resource adapter) will sleep for
        endpointExceptionRedeliveryInterval and then invoke the MDB again with the same message. This will repeat for
        EndpointExceptionRedeliveryAttempts times.

        If, after calling onMessage() endpointExceptionRedeliveryAttempts times the MDB still throws an exception, then what
        happens next is determined by the sendUndeliverableMsgsToDMQ property.

        If sendUndeliverableMsgsToDMQ is set to true the message is then sent to the dead message queue. If
        sendUndeliverableMsgsToDMQ is not set the message is returned to the broker and it will be redelivered, causing the
        whole process to repeat.

        The above properties are all activation spec properties. The first post in this thread demonstrates how to configure them.

        > "/(Remember you've got a pool of MDBs, so if the MDB starts throwing
        > exceptions you'll see a sudden burst of, say, 32 exceptions, then a pause of
        > 18 seconds, when another burst of 32 exceptions, and so on.)/"
        >
        > In my case, I have a MDB that may receive many messages in a minute. These messages (the TO inside the message) may
        > already have been received previously. In this case, the MDB invokes a stateless session bean that will throw a
        > BOAlreadyExists exception. Inside MDB, I get the BOAlreadyExists exception and just log this event.
        > I have some problems because the pool seems "stop working" after a predefined number of these exceptions.

        If the MDB's onMessage() isn't throwing an exception, but logs a message and returns, then none of the above applies.
        Something else is going on.

        Show
        David Zhao added a comment - @Nigel http://www.java.net/forum/topic/glassfish/glassfish/jms-redelivery-interval-gf-21?force=231 =============================================== If a MDB throws an exception then Glassfish (actually the resource adapter) will sleep for endpointExceptionRedeliveryInterval and then invoke the MDB again with the same message. This will repeat for EndpointExceptionRedeliveryAttempts times. If, after calling onMessage() endpointExceptionRedeliveryAttempts times the MDB still throws an exception, then what happens next is determined by the sendUndeliverableMsgsToDMQ property. If sendUndeliverableMsgsToDMQ is set to true the message is then sent to the dead message queue. If sendUndeliverableMsgsToDMQ is not set the message is returned to the broker and it will be redelivered, causing the whole process to repeat. The above properties are all activation spec properties. The first post in this thread demonstrates how to configure them. > "/(Remember you've got a pool of MDBs, so if the MDB starts throwing > exceptions you'll see a sudden burst of, say, 32 exceptions, then a pause of > 18 seconds, when another burst of 32 exceptions, and so on.)/" > > In my case, I have a MDB that may receive many messages in a minute. These messages (the TO inside the message) may > already have been received previously. In this case, the MDB invokes a stateless session bean that will throw a > BOAlreadyExists exception. Inside MDB, I get the BOAlreadyExists exception and just log this event. > I have some problems because the pool seems "stop working" after a predefined number of these exceptions. If the MDB's onMessage() isn't throwing an exception, but logs a message and returns, then none of the above applies. Something else is going on.
        Hide
        Tom Mueller added a comment -

        Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.

        Show
        Tom Mueller added a comment - Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.
        Hide
        pedrofalcaocosta added a comment -

        I have this issue too. In my case, besides the annotations properly configured:

        activationConfig =

        { @ActivationConfigProperty(propertyName = "acknowledgeMode", propertyValue = "Auto-acknowledge"), @ActivationConfigProperty(propertyName = "endpointExceptionRedeliveryAttempts", propertyValue = "20"), @ActivationConfigProperty(propertyName = "sendUndeliverableMsgsToDMQ", propertyValue = "true")}

        These are being totally ignored.
        The message keeps being redelivered forever, because the transaction was rolledbacked by JPA.

        I had to annotate the method calling the persistence with @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW), but now I'm missing the retry feature, because the message is Acknowledged.

        I think this is an important issue for a JMS implementation.

        Show
        pedrofalcaocosta added a comment - I have this issue too. In my case, besides the annotations properly configured: activationConfig = { @ActivationConfigProperty(propertyName = "acknowledgeMode", propertyValue = "Auto-acknowledge"), @ActivationConfigProperty(propertyName = "endpointExceptionRedeliveryAttempts", propertyValue = "20"), @ActivationConfigProperty(propertyName = "sendUndeliverableMsgsToDMQ", propertyValue = "true")} These are being totally ignored. The message keeps being redelivered forever, because the transaction was rolledbacked by JPA. I had to annotate the method calling the persistence with @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW), but now I'm missing the retry feature, because the message is Acknowledged. I think this is an important issue for a JMS implementation.
        Hide
        David Zhao added a comment -

        pedrofalcaocosta:

        It has been fixed in MQ 5.0, which will be bundled to future GlassFish release. Please refer to MQ-134 for more details.

        Show
        David Zhao added a comment - pedrofalcaocosta: It has been fixed in MQ 5.0, which will be bundled to future GlassFish release. Please refer to MQ-134 for more details.
        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: