| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MQ Browse cursor hang nightmare |
« View previous topic :: View next topic » |
| Author |
Message
|
| iceage |
 Posted: Tue Jan 05, 2010 1:01 pm Post subject: MQ Browse cursor hang nightmare |
 |
|
Acolyte
Joined: 12 Apr 2006
Posts: 68
|
I am running into a issue with browse cursor , though there are msgs in the queue (Persient , Prioriorty - 0) , browse cursor will not advance with gmo.options of (X'11' - WAIT + BROWSE_FIRST).
Main problem here is , its not that it doesnt always work , it works randomly stops working after som idle period .
Quuee handle status shows "INACTIVE" - in manual it means , there is no pending MQGET with WAIT , but in my program printf after MQGET never gets printed ..
High level logic
Infinite loop
Browse_FIRST + Wait
Wait Interval : 30 second
Until Msg Available loop
gmo.matchoptions = MQMO_NONE
MQGET <==== hangs here
GMO to MSG_UNDER_CURSOR
MQGET
GMO to BROWSE_NEXT + Wait
End of inner
End of infinite loop
Any possible hypothesis ? |
|
| Back to top |
|
 |
| mvic |
| Posted: Tue Jan 05, 2010 1:16 pm Post subject: Re: MQ Browse cursor hang nightmare |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| iceage wrote: |
High level logic
| Code: |
Infinite loop
Browse_FIRST + Wait
Wait Interval : 30 second
Until Msg Available loop
gmo.matchoptions = MQMO_NONE
MQGET <==== hangs here
GMO to MSG_UNDER_CURSOR
MQGET
GMO to BROWSE_NEXT + Wait
End of inner
End of infinite loop |
|
I don't understand the looping aspects to this design. Would it be possible to post the actual code? It will help to use "code" tags as well - thanks. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jan 05, 2010 1:45 pm Post subject: Re: MQ Browse cursor hang nightmare |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| iceage wrote: |
| Any possible hypothesis ? |
Without the actual code, I'd hypothise that you're hitting some kind of thread / handle limit because you're not closing old cursors.
But a better question is why you're doing this. Browse cursors (even when they work) are hideously inefficient and you don't show any processing that would warrant browsing the message. Why not just get the message and have done? Why browse it first?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| zonko |
| Posted: Tue Jan 05, 2010 11:32 pm Post subject: |
|
|
Voyager
Joined: 04 Nov 2009
Posts: 78
|
why get msg under cursor?
you have not locker it, and another app may get it. just get it!
you are browsing all the msgs in the queue, and getting each one in turn. BROWSE_NEXT will read to the end of the queue and will miss msgs written to the queue after the browse cursor has passed. if you want to do that, fine, but allow for a 2033 when you reach the end of the queue, and start reading again from the beginning withn another BROWSE_FIRST.
better still, since you are reading all the msgs, do not use BROWSE_NEXT but use BROWSE_FIRST for every read, and cater for an empty queue.
as the code is, it is possible that another app will read the msg off the queue between the browse and the destructive get, so your code should either lock the msg during the browse, or it should cater for a reason code of MQRC_NO_MSG_UNDER_CURSOR, 2034. |
|
| Back to top |
|
|
| iceage |
| Posted: Wed Jan 06, 2010 4:57 am Post subject: |
|
|
Acolyte
Joined: 12 Apr 2006
Posts: 68
|
Thanks to all for your replies ...
| Quote: |
I don't understand the looping aspects to this design. Would it be possible to post the actual code? It will help to use "code" tags as well - thanks.
|
Logic here is to do a 2 pass scan , inner loop (browse , removes all msgs available now until queue empty) , outer loop - to rescan for missing msgs (uncomitted ones) that skipped past the cursor and to have a indefinite listener servicing the queue
I will post the code after removing some context information out of it - but ofcourse we do some business processing after initial browse and then destructively get the message ( i get the point we can do this in single shot under syncpoint and rollback - but this app need this design , because its following framework from previous such designs - PLEASE BEAR THIS).
| Quote: |
why get msg under cursor?
you have not locker it, and another app may get it. just get it!
|
We open queue in EXCLUSIVE code , so not to worry abt somebody hijacking the message
| Quote: |
you are browsing all the msgs in the queue, and getting each one in turn. BROWSE_NEXT will read to the end of the queue and will miss msgs written to the queue after the browse cursor has passed. if you want to do that, fine, but allow for a 2033 when you reach the end of the queue, and start reading again from the beginning withn another BROWSE_FIRST.
|
Yes agreed , to circumvent msgs that skip past cursor , we have outerloop start with FIRST to ensure rescan ..
And BTW MQ Version is 6.0.2.2 , checked up APAR site , didnt find anythign useful. |
|
| Back to top |
|
|
| mvic |
| Posted: Wed Jan 06, 2010 6:05 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| iceage wrote: |
| but ofcourse we do some business processing after initial browse and then destructively get the message |
This was not clear before.
I don't think this has been covered precisely in your other answers: why was the choice made to browse this queue? Why not just call MQGET(no-browse) to remove the messages in one shot?
| iceage wrote: |
| And BTW MQ Version is 6.0.2.2 , checked up APAR site , didnt find anythign useful. |
Maybe nothing related to this problem exactly, but still 6.0.2.2 is 2+ years old and is 6 fix packs behind. There's a lot of water under the bridge since then.
UPDATE: correct typo
Last edited by mvic on Wed Jan 06, 2010 6:09 am; edited 1 time in total |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jan 06, 2010 6:06 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| iceage wrote: |
| Logic here is to do a 2 pass scan , inner loop (browse , removes all msgs available now until queue empty) , outer loop - to rescan for missing msgs (uncomitted ones) that skipped past the cursor and to have a indefinite listener servicing the queue |
You are seriously reinventing a wheel here. By simply getting the message, you'll automatically sweep up messages as they get committed.
| iceage wrote: |
| but this app need this design , because its following framework from previous such designs - PLEASE BEAR THIS). |
I understand that. What you (or whoever's pushing this design) needs to understand is that times change, software changes and designs need to evolve. I'm guessing that this design sprang from some previous queue system that didn't have the facilities WMQ does.
If you're going to pay the license for WMQ, why not exploit it?
| iceage wrote: |
| We open queue in EXCLUSIVE code , so not to worry abt somebody hijacking the message |
So you're developing code which will not perform well (because the browse cursor is very inefficient) and one of the key points is you can't scale the solution because the design relies on only one instance servicing the queue? If you ever have significant message volumes, that's going to bite.
| iceage wrote: |
| And BTW MQ Version is 6.0.2.2 , checked up APAR site , didnt find anythign useful. |
I doubt many other people would be using browse like this to hit the problem. You could raise a PMR on it yourself of course.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Jan 06, 2010 7:05 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| ...cursor will not advance with |
gmo.options of (X'11' - WAIT + BROWSE_FIRST).[/quote]
You didn't literally set the gmo to a hex value, did you?
| Quote: |
| MQGET <==== hangs here |
What exactly do you mean by hangs?
Does MQ return a 2033?
Does this (destructive get) gmo include a waitinterval?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
