| Author |
Message
|
| kash3338 |
 Posted: Fri Feb 27, 2009 4:24 am Post subject: Doubt on behaviour of MQGet Node |
 |
|
Shaman
Joined: 08 Feb 2009
Posts: 709
Location: Chennai, India
|
Hi,
We are using MQGet node in our flow to read a "KeyXML" XML which holds a key value.
We have set the property of this MQGet as "Browse Only", but still when we trigger our flow with bulk of messages, only for the first message the "KeyXML" is browsed from MQGet node, for the rest of the messages it comes through the "No Messages" terminal of MQGet node.
When we tried browsing the queue specified in MQGet, we can find the message in it.
Our flow is :
MQInput-->Compute-->MQGet-->Compute-->MQOutput.
Version of MB used : 6.1
Can anyone tell why ths behaviour of MQGet is like this?
Regards,
Kashyap. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Fri Feb 27, 2009 4:44 am Post subject: Re: Doubt on behaviour of MQGet Node |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| kash3338 wrote: |
| Can anyone tell why ths behaviour of MQGet is like this? |
Because MQGet is built like that?
Like any MQGet call, it will retrieve the first available message from the queue. On the next pass through your flow it will do the same. If nothing's read the message off in the meantime, you'll get the same message again.
As the MQGet node will only search for messages with a specific value in either MsgId or CorrelId, I assume you're using these as string fields to hold this XML. This is a bad idea in more ways than I care to name here, but will come up on a search of the forum! 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| kash3338 |
| Posted: Fri Feb 27, 2009 4:49 am Post subject: Re: Doubt on behaviour of MQGet Node |
|
|
Shaman
Joined: 08 Feb 2009
Posts: 709
Location: Chennai, India
|
| Vitor wrote: |
| kash3338 wrote: |
| Can anyone tell why ths behaviour of MQGet is like this? |
Because MQGet is built like that?
Like any MQGet call, it will retrieve the first available message from the queue. On the next pass through your flow it will do the same. If nothing's read the message off in the meantime, you'll get the same message again.
As the MQGet node will only search for messages with a specific value in either MsgId or CorrelId, I assume you're using these as string fields to hold this XML. This is a bad idea in more ways than I care to name here, but will come up on a search of the forum! |
Actually we want the same message browsed every time the flow runs. For the first time, the message is getting browsed properly, only the problem comes from the second message.
Is there any other property to be set in MQGet node? |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Feb 27, 2009 4:52 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
As my esteemable colleague says, the MQGET node is working the way it is because you have exactly and specifically told it to work exactly and specifically that way.
If you expect it to work differently, then you should review the properties you HAVE set on the node and then review the properties you HAVEN'T set on the node, as well as reviewing the documentation on those properties.
Then you can form a hypothesis about why the configuration you have made does what it does, and from there you can run experiments with other configurations to see what they do.
From all of that, then you will know WHY the MQGet node does what it does.
Somewhere in this process, you may also discover how to configure it to do what you WANT, which you haven't explained nor asked for help on. Presumably because you're already reviewing other posts in this forum and the documentation and developerworks and other sources of information more reliable than "the kindness of strangers'. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Feb 27, 2009 5:00 am Post subject: Re: Doubt on behaviour of MQGet Node |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| kash3338 wrote: |
Actually we want the same message browsed every time the flow runs. For the first time, the message is getting browsed properly, only the problem comes from the second message.
|
So you have a single "KeyXML" message on a queue. You put a number of messages on a different queue, read these with the MQInput node and expect each one to find the "KeyXML" message on it's queue?
Aside from not thinking about what the MQGet node is doing, this is a really daft and inefficient design. Queues are not built to store data. Browse is particually inefficient. If you've got key values that you need to find in a flow, store them in a database (or other construct) and read them from there. It's much clearer from a design standpoint, much more efficient from a runtime perspective.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| kash3338 |
| Posted: Fri Feb 27, 2009 5:27 am Post subject: |
|
|
Shaman
Joined: 08 Feb 2009
Posts: 709
Location: Chennai, India
|
Hi,
Just to give some more details,
The MQGET node is used with Browse option and with MATCH CORRELID option.
The message flow is like this
MQInput ->Compute-> MQGet->Compute->OutputNode
In a local queue we have stored a message with a specific correllation id which needs to be picked up by the MQGET node based on the input message
This works fine for the first few input messages or sometimes for 1-2 messages. After which the MQGet throws the control to no message terminal, even when there are messages present in the MQGet queue that match the correl id specified in the MQGET node. Is it because the previous browse of the same message is keeping a lock on the message? This behavior is seen when there are repeated browse of the same message in a frequent interval.
Could anyone please help on this? |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Feb 27, 2009 5:30 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| kash3338 wrote: |
| In a local queue we have stored a message with a specific correllation id which needs to be picked up by the MQGET node based on the input message |
Oops.
Do not set ids to values. It implies they are strings and they are not.
I repeat my previous comments about this being an inefficient way of storing data. Especially browsing a queue of any size.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| kash3338 |
| Posted: Fri Feb 27, 2009 5:42 am Post subject: |
|
|
Shaman
Joined: 08 Feb 2009
Posts: 709
Location: Chennai, India
|
| Vitor wrote: |
| kash3338 wrote: |
| In a local queue we have stored a message with a specific correllation id which needs to be picked up by the MQGET node based on the input message |
Oops.
Do not set ids to values. It implies they are strings and they are not.
I repeat my previous comments about this being an inefficient way of storing data. Especially browsing a queue of any size. |
The size of the data persisted in queue is very small and hence i feel storing it in a DB will be less efficient than browsing it through queue.
But basically i want to know if this kind of scenario is possible through MQGet. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Feb 27, 2009 6:03 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| kash3338 wrote: |
| The size of the data persisted in queue is very small and hence i feel storing it in a DB will be less efficient than browsing it through queue. |
Any database will outperform any queue browse, especially when doing a keyed read and very especially when the data is small because the database will cache it and the queue manager won't.
| kash3338 wrote: |
| But basically i want to know if this kind of scenario is possible through MQGet. |
You'll need to overcome some issues. You've found one of them (the browse cursor); one possible method is to throw a exception when you get a "No Message". This will cause the message to roll back onto the input queue and retry. You'll need to set the backout count to a high enough value that the message doesn't actually backout before it's processed, and put in some kind of filter logic so that "real" errors don't continuously retry.
You may also find issues if you are using the id fields as strings.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| chids |
| Posted: Fri Feb 27, 2009 6:16 am Post subject: Re: Doubt on behaviour of MQGet Node |
|
|
Novice
Joined: 09 Oct 2006
Posts: 22
Location: Stockholm, Sweden
|
| kash3338 wrote: |
Hi,
We are using MQGet node in our flow to read a "KeyXML" XML which holds a key value.
We have set the property of this MQGet as "Browse Only", but still when we trigger our flow with bulk of messages, only for the first message the "KeyXML" is browsed from MQGet node, for the rest of the messages it comes through the "No Messages" terminal of MQGet node.
When we tried browsing the queue specified in MQGet, we can find the message in it.
Our flow is :
MQInput-->Compute-->MQGet-->Compute-->MQOutput.
Version of MB used : 6.1
Can anyone tell why ths behaviour of MQGet is like this?
Regards,
Kashyap. |
Just to recap so that I understand. You have data on a queue. In your flow you'd like to retrieve a specific message message but not remove it from the queue (ie browse). Correct?
In browse mode the MQGet node maintains a browse cursor which causes you to browse the message the first time. But the second time the cursor have "passed" that message and hence you don't retrive it. Circumvent this by setting the MQGMO_BROWSE_FIRST option to the MQGet node using the LocalEnvironment as specified in the InfoCenter at page ac20806.
I'm not 100% sure on the syntax here but I would guess that it'd be:
| Code: |
OutputLocalEnvironment.MQ.GET.MQGMO_BROWSE_FIRST = 1
|
_________________
/mårten.
-- http://marten.gustafson.pp.se/
-- marten.gustafson@gmail.com |
|
| Back to top |
|
|
| zpat |
| Posted: Fri Feb 27, 2009 6:48 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5849
Location: UK
|
More like something resembling (and this is a guess)
| Code: |
| SET LocalEnvironment.MQ.GET.MQGMO = MQGMO_BROWSE_FIRST; |
You normally add MQGMO options together but it may do this for you and therefore need a different style of construct. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Feb 27, 2009 7:50 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7716
|
| Vitor wrote: |
Any database will outperform any queue browse, especially when doing a keyed read and very especially when the data is small because the database will cache it and the queue manager won't.
|
Will it? I dunno, asking. If that's so, why does MQ and WMB use queues to store so much internal data? If MQ and WMB want to be as fast as possible, wouldn't they come with a little database and get rid of 90% of the SYSTEM.* queues?
Then again maybe a DB read is faster than a q read.
DB read takes 0.0001 seconds
Q read takes 0.0002 seconds
(not real #s, just making them up)
Wow! the DB read is twice as fast as the q read.....but who cares when you are talking about 0.0001 seconds.
Using the MQGET node to browse shallow queues with small messages I think makes more sense than calling out to a DB, especially if that DB is remote. Simpler architecture, less things to go wrong, etc.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
