Author |
Message
|
ragup |
Posted: Fri Oct 21, 2011 10:59 pm Post subject: Read only specific data from Queue |
|
|
Newbie
Joined: 21 Oct 2011 Posts: 7
|
Hi,
As my requirement,I have to read a data from Reply queue after Put a message to request queue and also this reply queue some time contains a lot of information that has been requested by other clients(not relevant to my request)
In this scenario,when I am reading a message from Reply queue through .Net code the data will be deleted automatically from this queue after reading process is completed.
Here my concern is How can I find and get the data from reply queue that is releated to my request? And also How can I delete the data that is related to my request after read operation done. |
|
Back to top |
|
 |
shashivarungupta |
Posted: Fri Oct 21, 2011 11:21 pm Post subject: |
|
|
 Grand Master
Joined: 24 Feb 2009 Posts: 1343 Location: Floating in space on a round rock.
|
Quote: |
..read a data from Reply queue after Put a message to request queue and also this reply queue.. |
when in client target architecture, which is following request-reply scenario, they generally follow the msg-id : correlation-id feature to get the reply msg (with correl id) which matches with msg id of request msg.
but in your case, if multiple apps. are putting replies on the same queue in response of single / multiple request msgs then you need to check payload of the reply msg which matches the criteria.
But here's interesting question that how you would get the msg from the queue which is of your interest (and msg is not at the top of stack may be its in middle of the queue depth).
why diff. queues are not allocated to diff. apps. that would simplify the system that you have !
 _________________ *Life will beat you down, you need to decide to fight back or leave it. |
|
Back to top |
|
 |
zpat |
Posted: Fri Oct 21, 2011 11:30 pm Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
No, you get your own reply (or replies) messages based on correlid matching and using destructive MQGET (under syncpoint).
When you are ready, commit the syncpoint.
It may be advisable to set (fairly long) expiry times on reply messages (in case no-one gets them for whatever reason) to avoid long-term buildup of orphaned messages.
Of course the MQGMO_WAIT time can be used to decide how long to wait for the reply to arrive - as always provide logic to cope with any situation (like no reply from the service).
If you are talking about scanning queues looking for contextual data values - this is another matter entirely. |
|
Back to top |
|
 |
ragup |
Posted: Sat Oct 22, 2011 12:52 am Post subject: |
|
|
Newbie
Joined: 21 Oct 2011 Posts: 7
|
Thanks for reply.
anybody can tell how can I get a message based on Messageid and correlation id in mQ. |
|
Back to top |
|
 |
zpat |
Posted: Sat Oct 22, 2011 2:08 am Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
It's a option when using MQGET. Actually a little fiddly to code. What language are you using?
Look in the infocenter for keywords like "match_correlid", etc. There are probably some examples.
You could experiment with the MQI exceriser contained in support pac MO71 (the swiss-army knife of MQ utilities). |
|
Back to top |
|
 |
shashivarungupta |
Posted: Sun Oct 23, 2011 2:47 am Post subject: |
|
|
 Grand Master
Joined: 24 Feb 2009 Posts: 1343 Location: Floating in space on a round rock.
|
zpat wrote: |
What language are you using? |
.Net !
@ragup
Even you make the search on MQSeries.net forum, you would find lots of useful discussions on mesgid, correl id. _________________ *Life will beat you down, you need to decide to fight back or leave it. |
|
Back to top |
|
 |
bruce2359 |
Posted: Sun Oct 23, 2011 5:10 am Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
Search google for mq+request+reply+model _________________ 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 |
|
 |
|