| Author |
Message
|
| starki78 |
 Posted: Sat May 07, 2011 12:50 am Post subject: Message is not remaining in Backout requeue queue |
 |
|
Acolyte
Joined: 24 Sep 2007
Posts: 53
|
Hi I've the following problem/scenario
I've a Queue where a Message Driven Bean is listening, XA is enabled.
This MDB throws an error
Unter Storage-Section of the queue I define a Backout requeue queue
I set this queue to persistent
I set backout threshold = 10.
I set Harden get backout: hardened.
Observation: After 10 retries the message gets rolledback
and appears in the Backout requeue queue.
There is no attempt to process the message anymore.
--> this is fine
However then monitoring the queues the message seems to be present once in the request
queue and once in the error queue.
Once the consumer is stopped they appear in the request-queue.
I don't understand this.
I have a MQXAConnection Factory.
How can I achieve that they permanently remain in the Backout requeu queue?
Do I need to terminate the transaction? If yes how?
Is there any abondon timeout of this transaction?
Sorry if I miss something here I didn't find the answer in the forum
Cheers |
|
| Back to top |
|
 |
| exerk |
| Posted: Sat May 07, 2011 4:44 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
What are you doing with the 'original' message once it has been written to the back-out queue as a new message?
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| starki78 |
| Posted: Sat May 07, 2011 5:26 am Post subject: |
|
|
Acolyte
Joined: 24 Sep 2007
Posts: 53
|
regarding:
What are you doing with the 'original' message once it has been written to the back-out queue as a new message?
(1) Yes the goal is to have the message in the back-out-queue and the transaction being rolledback.
After that there should be a manual review of the message as there must be a reason why it has not been processed.
E.g. it was a MapMessage while a TextMessage was needed.
Can you help me to achieve (1)?
Thanks |
|
| Back to top |
|
|
| exerk |
| Posted: Sat May 07, 2011 5:44 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
I asked "...What are you doing with the 'original' message once it has been written to the back-out queue as a new message?...", and you answered that you are rolling it back to the original queue. So, why do you think you now have duplication of the message? Note I have re-emphasised part of my original question.
| starki78 wrote: |
| (1) Yes the goal is to have the message in the back-out-queue and the transaction being rolled back. |
That should not be your goal, which should be to have application-processable messages on the input queue or application-unprocessable messages on the back-out queue. You are almost there, and if you think through the logic of what you are doing you will spot the answer yourself.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| starki78 |
| Posted: Sat May 07, 2011 6:06 am Post subject: |
|
|
Acolyte
Joined: 24 Sep 2007
Posts: 53
|
sorry I don't understand your point.
seems you cannot compare a backout queue with an error queue.
In an error queue, e.g. in WebLogicJMS no new message gets created but
the old/original will be dropped when it cannot be delivery.
seems the concepts are different
Thanks anyway |
|
| Back to top |
|
|
| exerk |
| Posted: Sat May 07, 2011 6:24 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
With WMQ, when you get a message it's deleted from the queue never to be available again. A message got within a Unit-of-Work can be rolled back because it is only marked for deletion until the UoW is committed, after which it is deleted. Messages being put to back-out queues are new messages, not the message that was got.
Your logic should be something like (UoW assumed):
1. GET message;
2. Process and commit or roll-back to input queue;
3. PUT on back-out requeue and commit GET;
You need to discard the content of the message buffer when you have put the message on the back-out queue.
You say that with WebLogicJMS no 'new' message will be created, i.e. the backed-out-and-requeued message, but are you absolutely sure that what I have described above is not going on under the covers?
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| starki78 |
| Posted: Sat May 07, 2011 7:52 am Post subject: |
|
|
Acolyte
Joined: 24 Sep 2007
Posts: 53
|
Regarding:
You say that with WebLogicJMS no 'new' message will be created, i.e. the backed-out-and-requeued message, but are you absolutely sure that what I have described above is not going on under the covers?
no  , however the user needs not care about this
Thank you very much for your explanation - I'll work on this suggestion.
Have a nice rest-weekend |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat May 07, 2011 8:58 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
I seem to remember reading somewhere about a twist in the process that puts the messages to the backout queue:
If the messages being put to the backout queue are the last messages being processed (i.e. there never was a successful message after that) there is an open transaction and the message(s) on the backout queue will get committed with the next successful message.
So in your case, if you stop the mdb there is no next successful message and the message(s) on the backout queue gets rolled back to the input queue.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| starki78 |
| Posted: Sun May 08, 2011 2:29 am Post subject: |
|
|
Acolyte
Joined: 24 Sep 2007
Posts: 53
|
this is correct.
I've verified this right now. Only after a new message can be processed successfully the bad messages remain permanently in the error-queue.
Thank you very much
 |
|
| Back to top |
|
|
|
|
