Author |
Message
|
wmq_guy |
Posted: Fri Dec 03, 2004 10:11 am Post subject: MDB message fails (ListenerPort retries/JMSredeliverCount) |
|
|
Acolyte
Joined: 21 Oct 2004 Posts: 50
|
Question
If I set up the Maxretries on the ListenerPort above 1, but I dont want the message to just keep on trying and loop forever,
I was thinking I can just add logic to the beginning of the onMessage() to check for redelivered..
so if i check the very first time..
isRedelivered = msg.getJMSRedelivered();
I should get false,
if it fails and retries and the MDB checks again it would be true?
who sets this field anyway, the container?
I tried to test it out and change the DeliveryCount to 2 but it throws:
javax.jms.MessageNotWriteableException: MQJMS0008: JMS Client attempts to write a read-only message
how to most people work with this sort of design??
lastly,
if I write a little tester put message java program to throw messages on the queue the MDB is listening to, whats a good back to make it fail on purpose to test this ...
thanks |
|
Back to top |
|
 |
bower5932 |
Posted: Fri Dec 03, 2004 10:31 am Post subject: |
|
|
 Jedi Knight
Joined: 27 Aug 2001 Posts: 3023 Location: Dallas, TX, USA
|
The redelivered and delivery count fields are set by WMQ to let you know that this message is being redelivered and how many times it has been. It gives you the opportunity to do something. It isn't a field that you set which is why you get the error about it being read only.
I believe the maximum number of retries on the listener port tells how many times to redeliver a message before shutting down the port. You probably don't want this, so there is also a backout threshold on the underlying WMQ queue. This allows the message to be moved to a backout queue so that the listener port isn't stopped.
When I try to test failures, I send a message that has 'back' in it. I then test for this and if I found it, I rollback the message. You'll also need to make sure that you use container managed transactions rather than bean managed. Container managed transactions will allow the get of the message to be part of the unit of work. |
|
Back to top |
|
 |
wmq_guy |
Posted: Fri Dec 03, 2004 11:22 am Post subject: |
|
|
Acolyte
Joined: 21 Oct 2004 Posts: 50
|
thanks.
So I checked under storage tab for the Queue on the MQexplorer and it has three settings:
backout requeue name
backout threshold
harden get backout
so you are saying I need to coordinate this with my listenerport
I basically dont want the listenerport to shutdown of a message is bad but I dont want it to just keep retrying forver either..
So, as an expample set the listener port to maxretries 2
and set these three fields to ..
requeue name = ErrorQueue
backout threshhold = 1
harden get backout = hardened ??
so it would just shoot any messages that fail to the ErrorQueue?
AND..
it keeps referring to BACKED OUT, is this the same as retries for the listenerPort??
thanks |
|
Back to top |
|
 |
bower5932 |
Posted: Fri Dec 03, 2004 1:19 pm Post subject: |
|
|
 Jedi Knight
Joined: 27 Aug 2001 Posts: 3023 Location: Dallas, TX, USA
|
Yes, you need to coordinate the backout values on the queue with the listener port. You might want to go with values that are higher than 1 and 2. It is possible that a message being bad is transient and you'd want to try again. With the listener port, I like to have a couple of messages worth of slack in the count. I believe that the default for WAS for the backout count is 5. I set my listener port to 10. |
|
Back to top |
|
 |
wmq_guy |
Posted: Fri Dec 03, 2004 6:29 pm Post subject: |
|
|
Acolyte
Joined: 21 Oct 2004 Posts: 50
|
awesome.
I will try it out
I will set my listener to 10 and the backout to 5
So you use the harden backout?
also, what exactly do you mean the message may be 'transient' so I may want to try it again.
thanks alot |
|
Back to top |
|
 |
fjb_saper |
Posted: Sat Dec 04, 2004 5:46 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
The rollback condition may be transient: example db locks etc...
This is why you want to retry multiple times.
Enjoy  |
|
Back to top |
|
 |
bower5932 |
Posted: Sun Dec 05, 2004 3:48 am Post subject: |
|
|
 Jedi Knight
Joined: 27 Aug 2001 Posts: 3023 Location: Dallas, TX, USA
|
Personally, I don't harden the backout count. There are others who would probably swear by doing it. |
|
Back to top |
|
 |
wmq_guy |
Posted: Mon Dec 06, 2004 7:41 am Post subject: |
|
|
Acolyte
Joined: 21 Oct 2004 Posts: 50
|
Thanks Bower,
what exactly would it gain you anyway using harden backout? |
|
Back to top |
|
 |
bower5932 |
Posted: Mon Dec 06, 2004 8:47 am Post subject: |
|
|
 Jedi Knight
Joined: 27 Aug 2001 Posts: 3023 Location: Dallas, TX, USA
|
Hardening the backout count would ensure that "the count of the number of times that a message has been backed out is accurate". This is quoted from the MQSC manual. I guess if it was really critical that this value always be accurate, then you should harden it. I've always felt like if it was 'close enough', then I could live with it. Somebody in a 'mission critical' environment might argue for setting int. |
|
Back to top |
|
 |
fjb_saper |
Posted: Mon Dec 06, 2004 9:15 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
As per the manual, depending on platform you may have no choice.
From memory, I believe that on Unix platform the backout is always hardened regardless of the setting.
Enjoy  |
|
Back to top |
|
 |
bower5932 |
Posted: Mon Dec 06, 2004 9:56 am Post subject: |
|
|
 Jedi Knight
Joined: 27 Aug 2001 Posts: 3023 Location: Dallas, TX, USA
|
On Tandem, you have no choice. Persistent messages use a hardened backout count and non-persistent messages don't. |
|
Back to top |
|
 |
|