Issue Details (XML | Word | Printable)

Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Minor Minor
Assignee: David Zhao
Reporter: beniamin
Votes: 3
Watchers: 2

If you were logged in you would be able to see more operations.

Ignoring MDB's activation-spec for RedeliveryInterval and RedeliveryAttempts

Created: 22/Oct/08 07:47 AM   Updated: 10/Oct/12 07:02 PM   Resolved: 25/Jul/12 05:21 AM
Component/s: jms
Affects Version/s: 9.1peur2
Fix Version/s: 4.0_b45

Time Tracking:
Issue & Sub-Tasks
Issue Only
Not Specified


Operating System: Windows XP
Platform: PC

Issuezilla Id: 6,617
Participants: amyk, beniamin, David Zhao, gfuser9999, pedrofalcaocosta, sanandal, stenlee and Tom Mueller

  • Sub-Tasks:
  • All
  • Open

 Description  « Hide

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


beniamin added a comment - 28/Oct/08 01:04 AM

Nobody is interested in it.

sanandal added a comment - 11/Jan/09 07:01 AM

"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."

stenlee added a comment - 01/Mar/09 02:07 PM
      • Issue 6617 has been confirmed by votes. ***

stenlee added a comment - 01/Mar/09 02:12 PM

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

beniamin added a comment - 01/Mar/09 02:24 PM

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

David Zhao added a comment - 15/Feb/12 02:33 AM


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.

Tom Mueller added a comment - 06/Mar/12 09:57 PM

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

pedrofalcaocosta added a comment - 08/Mar/12 07:27 PM

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.

David Zhao added a comment - 12/Mar/12 06:49 AM


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

David Zhao added a comment - 12/Mar/12 06:51 AM

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

David Zhao added a comment - 25/Jul/12 05:21 AM

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

gfuser9999 added a comment - 25/Jul/12 02:26 PM

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,
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 .....

David Zhao added a comment - 18/Sep/12 01:51 AM


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.

amyk added a comment - 10/Oct/12 07:02 PM

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