[GLASSFISH-6617] Ignoring MDB's activation-spec for RedeliveryInterval and RedeliveryAttempts Created: 22/Oct/08  Updated: 20/Dec/16  Resolved: 25/Jul/12

Status: Resolved
Project: glassfish
Component/s: jms
Affects Version/s: 9.1peur2
Fix Version/s: 4.0_dev

Type: Bug Priority: Minor
Reporter: beniamin Assignee: David Zhao
Resolution: Fixed Votes: 3
Labels: None
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Operating System: Windows XP
Platform: PC
URL: http://forums.java.net/jive/thread.jspa?threadID=50212&tstart=50

GLASSFISH-18940 Add new property "imq.transaction.mes... Sub-task Open Mike Fitch  
Issuezilla Id: 6,617


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


Comment by beniamin [ 28/Oct/08 ]

Nobody is interested in it.

Comment by sanandal [ 11/Jan/09 ]

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

Comment by stenlee [ 01/Mar/09 ]
      • Issue 6617 has been confirmed by votes. ***
Comment by stenlee [ 01/Mar/09 ]

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

Comment by beniamin [ 01/Mar/09 ]

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

Comment by David Zhao [ 15/Feb/12 ]

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

Comment by Tom Mueller [ 06/Mar/12 ]

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

Comment by pedrofalcaocosta [ 08/Mar/12 ]

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.

Comment by David Zhao [ 12/Mar/12 ]


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

Comment by David Zhao [ 12/Mar/12 ]

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

Comment by David Zhao [ 25/Jul/12 ]

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

Comment by gfuser9999 [ 25/Jul/12 ]

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

Comment by David Zhao [ 18/Sep/12 ]


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.

Comment by amyk [ 10/Oct/12 ]

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

Generated at Mon Jan 23 07:12:33 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.