| Author |
Message
|
| jefflowrey |
 Posted: Mon Jul 11, 2005 6:17 am Post subject: Backout Requeue on a Topic... |
 |
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
If I set a BOQNAME and BOTHRESH on the SYSTEM.JMS.D.CC.SUBSCRIBER.QUEUE or the SYSTEM.JMS.D.SUBSCRIBER.QUEUE, will it get honored by the MQ Pub/Sub broker, or a WAS 5.1 MDB?
The discussions in the WebSphere Admin console suggest that backout handling is performed by the Connection Consumer, so I would think that the MDB that is supposed to be processing the subscriptions (and failing) would do the backout processing...
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Tue Jul 12, 2005 5:21 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Well, I guess I have to try it and see.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Jul 12, 2005 1:13 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Jeff,
This really depends on your environment.
!) set a backout threshold on the queue
2) back out the message once more than the threshol.
3) enjoy the differences.
Note : This really works well with IBM WAS MDBs where the message is put to the SDLQ if no backout destination is found.
Enjoy  |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Jul 12, 2005 2:11 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| fjb_saper wrote: |
| This really depends on your environment. |
On what parts of my environment does it depend? As should have been clear, my environment consists of MDBs running under WAS 5.1, acting as subscribers to topics under control of an MAOC/MQ broker - not a WBIMB broker or the embedded messaging broker.
| fjb_saper wrote: |
| Note : This really works well with IBM WAS MDBs where the message is put to the SDLQ if no backout destination is found. |
In fact, I think I've noticed that publications that can't be received by subscribers go to the SDLQ if the SYSTEM.JMS.D.CC.SUBSCRIBER.QUEUE is full.
That would actually be what I am trying to prevent.
So, again, if I set a backout retry queue and a backout retry count on SYSTEM.JMS.D.CC.SUBSCRIBER.QUEUE, will it get honored?
Please understand that this message is merely a request for clarification of what you have already said.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Jul 12, 2005 6:10 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Per MQ Manual:
The responsibility for Backout mechanism relies with the application.
Don't remember if WAS or MQ manual:
If the application is IBM WAS the behavior is as follows:
If there is a BO set (> 0)and the MDB has a retry of at least BO + 1
a) with BO Destination
after the BO is reached the message is moved to the BO Destination.
b) without a BO Destination
after the BO is reached the message is moved to the SDLQ reason 2362 (? from memory) with DLQ header...
For this to happen there is a need for the application to try to process the message BO times and raise the appropriate rollback / exception forcing the container/bean managed transaction to roll back.
Now if your messages are on the queue because the subscriber does not retrieve them this won't help you as you will never have BO gets on the message!
Sending messages to the SDLQ if the queue is full (reason 2352) is the normal behavior.
We have a P2P model.
We have a app consuming a Q (MDB) BO Threshold = 3 MDB retry=4
If there is a problem with the 2 phase commit the MDB/Container transaction does a rollback.
We log errors. We get 3 errors per message in the DLQ with reason BO Threshold reached and Destination our app queue.
Hope this clarifies a bit.
In essence:
a) Why does your subscriber queue get full:
1) the subscription is dead (network disc.) but the qmgr / broker does not know it. -- This won't help you a bit as BO is never reached
2) The subscription is dead because
-- you received a poison message
-- you have no BO and the number of MDB retries has been exhausted
-- as a consequence the MDB port has shut down
-- solution recycle WAS...... not pretty...
-- Here the BO threshold will help as the poison msg will go to the SDLQ (Yes!) or the BO Destination.
B) you may want to look to a monitoring solution to check if all the subscribers are still connected when the situation happens.
My guess is that you are using a client connection to a qmgr not on the WAS server. I would recommand against it in this scenario.
 |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Jul 13, 2005 3:25 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| fjb_saper wrote: |
| a) Why does your subscriber queue get full: |
That is the 20,000 message question.
| fjb_saper wrote: |
| 1) the subscription is dead (network disc.) but the qmgr / broker does not know it. -- This won't help you a bit as BO is never reached |
True. But if I can get any sort of BO working, it will help identify when this is the case, and when it's something else.
| fjb_saper wrote: |
2) The subscription is dead because
-- you received a poison message
-- you have no BO and the number of MDB retries has been exhausted
-- as a consequence the MDB port has shut down
-- solution recycle WAS...... not pretty...
-- Here the BO threshold will help as the poison msg will go to the SDLQ (Yes!) or the BO Destination. |
Again, though, this is an MDB on a Topic. So it's only indirectly associated with a queue, and that queue seems to be SYSTEM.JMS.D.CC.SUBSCRIBER.QUEUE.
| Quote: |
| B) you may want to look to a monitoring solution to check if all the subscribers are still connected when the situation happens. |
We have an official standard for monitoring. We do not yet have, and it will likely be several months until we get, the WebSphere and MQ monitoring components of that tool.
| Quote: |
| My guess is that you are using a client connection to a qmgr not on the WAS server. I would recommand against it in this scenario. |
Nope. It's a binding connection for the subscriptions.
In... most ... cases. hrm.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Jul 13, 2005 4:31 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Well Jeff,
This clarifies things quite a bit. I guess in your case it would most likely be reason 2: poison message. You should be able to see that if the dequeue rate is 0....
In the interim maybe you can use netflexity for monitoring this scenario...
To see further you can change your MDB...
a) create an official backout queue.
b) change the MDB. Have it check the BO count on the message.
If the bo count is more than X -1 move the message to the BO queue.
c) make sure that in case b the MDB ends on a transaction success....
d) analyse the messages in the BO queue and find out why...
Or check back with the previous post, determine which queue is feeding the Topic to your MDB. This is specified in the broker manual (or using java for the internal broker). Ultimately the Topic removes a message from a queue.
You can specify a queue for the messages when subscribing to the topic. So I would suggest you do that and make sure you have a BO threshold on that queue. Analyze the messages in the DLQ. Check the reason codes.
Sorry no other ideas.
|
|
| Back to top |
|
|
|
|
