| Author |
Message
|
| jim777 |
 Posted: Thu Mar 08, 2012 8:48 pm Post subject: Browsing MQInput Node with Reset Browse Timeout |
 |
|
Novice
Joined: 13 Feb 2012
Posts: 16
|
I have the MQInput node browse only option checked and the reset browse timeout set to 5 minutes.
Here is my flow
MQInput (browse) -> compute node -> MQGet (if condition met)
Is there any indicator that I can query or check to see if this is this reset browse timeout has been reset and that I am browsing my Queue from the beginning again?
I would like to reset some variables each time the reset browse timeout has been reached. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Fri Mar 09, 2012 5:58 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
What's the requirement behind this slightly odd design?
It looks a bit like you're trying to read with an MQGet when a given message is present on the MQInput queue. There are any number of better ways to do that.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Fri Mar 09, 2012 6:03 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
Seems like you are trying to time the consumption of a message with an external event. Your design is not an efficient use of system resources. You could create a timer object to test the event condition and perform an action if satisfied. That way you avoid browsing the queue multiple times.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Mar 09, 2012 6:18 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You can certainly cache information about 'the first' message and then compare it with each message you receive.
Once it matches again, you know you are back at 'the first' message. |
|
| Back to top |
|
|
| jim777 |
| Posted: Fri Mar 09, 2012 6:24 am Post subject: |
|
|
Novice
Joined: 13 Feb 2012
Posts: 16
|
I'm browsing data off the MQInput node and if it fits certain criteria then I pull it off using the MQGet. Then I would need to traverse the rest of the queue looking for messages that fit the same criteria as the first message.
Here's an example
Queue has:
1
2
3
1
3
The first message is 1 so I would pull it off as well as the fourth message thus leaving the queue like this:
2
3
3
The second iteration would just pull off 2 leaving
3
3
But all this happens while there are other processes adding data to this queue all the time. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Mar 09, 2012 6:33 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Possible design alternatives include, but are not limited to:
- Have the sending application(s) send messages with matching criteria in the same WMQ group and have the MQInput node honour the group
- Read all messages with an MQInput node and assemble messages with matching criteria with a Collector node
Other, possibly better, solutions are undoubtably possible.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Mar 09, 2012 6:34 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Right, so you need to tell the MQInput to *not* browse, and tell the MQGet node that it SHOULD browse.
You read the first message. You then pull all messages off the queue that match the first message. You then end processing the first message. If something goes wrong, you roll back the input message, and try again.
You then read the second message, and pull all messages off the queue that match this message.
Repeat.
This is the correct asynchronous messaging pattern for what you are trying to do, not the one you have outlined.
Another option is that you use Message Groups.
A third option is to use a filter approach, where you read each message, and kick it to queue 1, 2, 3, etc, based on it's matching criteria. Then you have a second flow process all the 1s, and another process all the 2's, and etc. etc. etc.
If the concern, somehow, is that you have to 'wait' for new messages that match the current message, you can indeed accommodate that with some careful thinking. |
|
| Back to top |
|
|
| jim777 |
| Posted: Fri Mar 09, 2012 7:04 am Post subject: |
|
|
Novice
Joined: 13 Feb 2012
Posts: 16
|
mqjeff, if I set the MQInput to "not" browse" and MQGet to "browse". I like that as well
In my sample data from above, after the MQInput I will have
2
3
1
3
If I use the MQGet on browse mode and move down the queue, after some computation I find out that a message matches the criteria from the first message [1], how would I point to it to pull it off because if I call another MQGet (with browse off) it will pull out [3] and I'll be left with
2
3
1 |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Mar 09, 2012 7:08 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| jim777 wrote: |
| If I use the MQGet on browse mode and move down the queue |
Bear 2 things in mind:
- WMQ browse is a slow operation
- Using an MQGet in a loop can cause memory issues and/or abends. There's discussion on this forum you may want to review on this subject.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Mar 09, 2012 7:18 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| jim777 wrote: |
| how would I point to it to pull it off because if I call another MQGet (with browse off) it will pull out [3] |
you tell it to get the message under the cursor, rather than getting the next message. |
|
| Back to top |
|
|
| jim777 |
| Posted: Fri Mar 09, 2012 7:23 am Post subject: |
|
|
Novice
Joined: 13 Feb 2012
Posts: 16
|
| Is that a property for the MQGet node? How do you tell the MQGet to get the message under the cursor, rather than getting the next message |
|
| Back to top |
|
|
|
|
