| Author |
Message
|
| ghoshly |
 Posted: Sun Aug 01, 2010 11:17 pm Post subject: Browse and then GET messages with the MQGet node |
 |
|
Partisan
Joined: 10 Jan 2008
Posts: 333
|
I have very similar requirement as shown in the given example of "Browsing WebSphere MQ Queues sample"
What I believe is the MQInput node or MQGet node performes a Browse Next by default instead of Browse Q as that would be helpful for many situation but I want to have the Browse Q only as I need to check the Queue depth and if there is any message in the queue, based on database connectivity (checked in the Next filter node) I need to get the message from the queue. So, if the DB is down, or any other condition fails, need to run the check again, but this time it checks with the next message on the queue and if there is a single message there in the queue, in the next attempt it is showing no message even if the message is still there in queue.
My current flow design :
TimeOutNotification ->Set_GMO(Compute) ->MQGet ->Filter ->MQGet -> OtherCompute
In that Set-GMO can I override the GMO option through which MQGet node acts like BrowseQ, so that even there is a single message, which was browsed earlier browses again using LocalEnvironment.MQ.GET. ??
Please help.  |
|
| Back to top |
|
 |
| zpat |
| Posted: Sun Aug 01, 2010 11:37 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
You realise this design looks totally wrong.
Why not start the flow when a message arrives (normal MQINPUT) and then if you can't connect to the database, roll back the transaction?
If this happens more than (n) times (backcount threshold) then the message goes to the backout queue for investigation of the problem.
As has been stated here many times. Applications should never normally need to browse a queue (or look at depth) and to do so is a sign that the design is wrong.
Timer polling a queue is usually wrong in any application, but in the broker when there is such good support for event driven design it is doubly wrong to do this.
IBM only added the MQGET node comparitively recently and it is only really needed for some more advanced situations. |
|
| Back to top |
|
|
| ghoshly |
| Posted: Mon Aug 02, 2010 12:24 am Post subject: |
|
|
Partisan
Joined: 10 Jan 2008
Posts: 333
|
As per :
http://www.mqseries.net/phpBB2/viewtopic.php?p=269001&highlight=&sid=abfc5f381becdaf9aa9f0a9b9c023a12
I understood that I need to reset the browse cursor of the MQGet and so I was trying to reset the cursor using
| Code: |
SET OutputLocalEnvironment.MQ.MQGET.MQGMO.Options = MQGMO_BROWSE_FIRST;
|
but seems not successful in that. Could you please help me in identifying my mistake.
I would try to design using back out threshold and events generated by broker, but it seems that some manual intervention would be required when the DB is up and running, and client wants to automate that process of retrial. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Aug 02, 2010 4:23 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| ghoshly wrote: |
| it seems that some manual intervention would be required when the DB is up and running, and client wants to automate that process of retrial. |
Of course some manual intervention is required - how exactly can you automate this? How will the system know when the database is back unless a human tells it?
What I suspect to be the case is there is a common issue with the database where a backup job has exclusive access to the tables or something, so retrying after 10 minutes is usually sufficient. That's all very well, but what happens when the sever goes down? Is this flow going to retry every 10 mins for 6 hours? Suppose it goes off when the DBAs have got the database back but in a inconsistent state?
Paradoxically, "manual intervention" can be automated. Especially if it's as simple as moving messages off a backout queue back onto the real input queue.
Rethink your design. Timers and browse? There has to be a better way.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| joebuckeye |
| Posted: Mon Aug 02, 2010 6:01 am Post subject: |
|
|
Partisan
Joined: 24 Aug 2007
Posts: 365
Location: Columbus, OH
|
| Quote: |
| Paradoxically, "manual intervention" can be automated. Especially if it's as simple as moving messages off a backout queue back onto the real input queue. |
This is what we did.
A message flow puts certain classes of errors on a retry queue. A cron job kicks of a MQ JMS app that reads the retry queue and looks for some retry parameters (either number of times or time based) and decides where the message goes. If the retry parameter values are less than the max the parameters are increased and put onto the original flow's input queue. If the parameter values are more than the max they get put onto the real reject queue that leads to a flow that sends an email to someone.
The MQ JMS app can use either number of times or max time to control when something is no longer retried. The cron timing controls how often this job is run.
The only issue with this method is that the message flow sending messages to the retry queue must make sure the RFH2 header is preserved as it contains the JMS properties that let the MQ JMS app know how many times the message has been retried. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Aug 02, 2010 6:30 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| joebuckeye wrote: |
| This is what we did. |
This is the sort of thing I was thinking of. Obviously there's manual intervention required once the messages are on the "real" reject queue, but that's as simple as manually running a differently configured version of this message moving app.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
