| Author |
Message
|
| fjb_saper |
 Posted: Wed May 07, 2008 9:26 pm Post subject: |
 |
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Try being a little bit more creative....
Schedule the original MDB to put the message on retry queue 1 -- scalability excellent
Schedule a process every retry int /2 against retry queue 1 -- Set queue delivery to FIFO. Browse 1st message. If age < retry age exit.
Else start x many process threads. If age < retry age rollback -- scalability x
The BO thresh for this queue should be at least 2 (ideally you might want to go to x+2) on bothresh)
Now look at the same process and apply to retry queue n
This should take care of your thousands of scheduled processes ...
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
 |
| nickt |
| Posted: Wed May 07, 2008 10:05 pm Post subject: |
|
|
Novice
Joined: 27 Apr 2008
Posts: 11
|
| fjb_saper wrote: |
Try being a little bit more creative....
Schedule the original MDB to put the message on retry queue 1 -- scalability excellent
Schedule a process every retry int /2 against retry queue 1 -- Set queue delivery to FIFO. Browse 1st message. If age < retry age exit.
Else start x many process threads. If age < retry age rollback -- scalability x
The BO thresh for this queue should be at least 2 (ideally you might want to go to x+2) on bothresh)
Now look at the same process and apply to retry queue n
This should take care of your thousands of scheduled processes ...
Enjoy |
Nice approach.... but how do the messages go from retry queue n to retry queue n+1 if they fail processing if the bothresh is 2? you have to read them off, then roll them back twice to make sure they requeue, then move on to the next message? Can you manually requeue a message?
I understand you set the bothresh to at least 2 so when you see the first message that's not ready for retry you can roll it back and end the processing run but it sounds a bit clunky to have to roll the message back twice (or more) to make it requeue in the event of a fail?
I want to retry once only at the first interval once only at the second and so forth. |
|
| Back to top |
|
|
| mvic |
| Posted: Thu May 08, 2008 1:53 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| nickt wrote: |
| In the event of an outage that prevented messages being processed immediately the retry queues could easily swell to thousands of messages (the application is quite busy) and this design would see one EJB timer created for every message on the retry queue. |
Is it possible to implement your backoutQ processor program such that it reads all messages non-selectively, and makes its handling decisions in code? All the selector performance worries will go away.
If you propose to do a get by-msgid off the backoutQ, then you're not really doing messaging any more - you may as well hand off the "bad" data direct to your backout processing by calling a backout processing function.
Sorry if any of this does not fit your scenario... 
(BTW i still think what you originally described sounds like a bug - please let us know what you find out from IBM support...) |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu May 08, 2008 9:52 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| nickt wrote: |
| Given your input I'm working now on implementing this in a way that plucks messages out by MsgId |
Just telling JMS to select by Message ID doesn't change this looping browsing behaviour. You have to use the 48 char hex representaion of the Message ID, prepended with "ID:".
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| nickt |
| Posted: Thu May 08, 2008 3:15 pm Post subject: |
|
|
Novice
Joined: 27 Apr 2008
Posts: 11
|
|
| Back to top |
|
|
| nickt |
| Posted: Thu May 08, 2008 6:00 pm Post subject: |
|
|
Novice
Joined: 27 Apr 2008
Posts: 11
|
Hi all,
Additionally after updating WMQ the problem persisted, but this is because the problem is in one of the:
com.ibm.mq.jar
com.ibm.mqjms.jar
dhbcore.jar
files in the WebSphere runtime. I overwrote those files (in the WebSphere/AppServer/lib/WMQ/java/lib folder with the new ones from the MQ 6.0.2.3 installation and everything's now working as expected. 
Cheers,
Nick |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri May 09, 2008 3:27 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| nickt wrote: |
Hi all,
Additionally after updating WMQ the problem persisted, but this is because the problem is in one of the:
com.ibm.mq.jar
com.ibm.mqjms.jar
dhbcore.jar
files in the WebSphere runtime. I overwrote those files (in the WebSphere/AppServer/lib/WMQ/java/lib folder with the new ones from the MQ 6.0.2.3 installation and everything's now working as expected.
Cheers,
Nick |
Don't do that. You should read the WAS manual.
Repoint the MQ_INSTALL variable to the right directory...
Enjoy
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
