Skip to main content

JMS Redelivery Interval (GF 2.1)

Please note these java.net forums are being decommissioned and use the new and improved forums at https://community.oracle.com/community/java.
4 replies [Last post]
culli
Offline
Joined: 2006-09-17

I'm not having any luck getting a JMS redelivery interval to work. Below is the xml from sun-ejb.jar.xml (right place?). I'd like to configure this in XML so if I want to change the interval later, I can do it without a recompile.

Dialing up the logging, I can see what I think is proof that the value is getting set. It's just not honoring the value. I am hoping to slow down the redelivery to be very slow, so when a third-party system is down we're not pounding them with messages. What am I missing?

            <ejb-name>MyMDBean</ejb-name>

            <jndi-name>jms/MyQueue</jndi-name>

            <mdb-resource-adapter>

                <resource-adapter-mid>jmsra</resource-adapter-mid>

                <activation-config>

                    <activation-config-property>

                        <activation-config-property-name>EndpointExceptionRedeliveryAttempts</activation-config-property-name>

                        <activation-config-property-value>1</activation-config-property-value>

                    </activation-config-property>

                    <activation-config-property>

                        <activation-config-property-name>EndpointExceptionRedeliveryInterval</activation-config-property-name>

                        <activation-config-property-value>180000</activation-config-property-value>

                    </activation-config-property>

                </activation-config>

            </mdb-resource-adapter>

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
nigeldeakin
Offline
Joined: 2007-10-12

On 12/12/2011 23:46, forums@java.net wrote:
> I'm not having any luck getting a JMS redelivery interval to work. Below
> is the xml from sun-ejb.jar.xml (right place?).

Yes, this looks fine.

> I'd like to configure this
> in XML so if I want to change the interval later, I can do it without a
> recompile.
>
> Dialing up the logging, I can see what I think is proof that the value
> is getting set. It's just not honoring the value. I am hoping to slow
> down the redelivery to be very slow, so when a third-party system is down
> we're not pounding them with messages. What am I missing?

You're using a relatively old version of GlassFish. Could you try using the latest version? It seems to work for me with
3.1.1.

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

Nigel

culli
Offline
Joined: 2006-09-17

nigeldeakin wrote:
You're using a relatively old version of GlassFish. Could you try using the latest version? It seems to work for me with 3.1.1. (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.) Nigel

We have converted our app to 3.1 and tried with 3.1.1 and 3.1.2, but we ran into a couple of bugs that were show-stoppers for us (one on 3.1.1 and one on 3.1.2). The bug in 3.1.1 was fixed in 3.1.2, but a bug in 3.1.2 makes that unworkable for us too. Another developer here has filed a bug report for the 3.1.2 bug (super-slow deploy).

Anyway, I've got this fixed. One problem was that doing a MessageDrivenContext.setRollbackOnly() doesn't cause the message to be redelivered like I believed it should have. To work around that I had to do: throw new RuntimeException(ex).

The second problem was that our code had an @AroundInvoke interceptor that was catching exceptions and seemed to be intefering with the redelivery process. From what I can tell we no longer need the interceptor, fortunately.

Gustavo Henriqu...
Offline
Joined: 2011-10-27

Hi Nigel,
Could you please explain better the delay behavior and how to change it?

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

nigeldeakin
Offline
Joined: 2007-10-12

On 14/12/2011 14:35, Gustavo Henrique Orair wrote:
> Hi Nigel,
> Could you please explain better the delay behavior and how to change it?

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.

Nigel