| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Architecture question |
« View previous topic :: View next topic » |
| Author |
Message
|
| timcl |
 Posted: Mon Jul 15, 2002 7:09 am Post subject: Architecture question |
 |
|
Novice
Joined: 16 May 2001
Posts: 23
Location: Australia
|
Hi,
We have 2 queue managers.
We have users on QMGR1 putting messages onto a remote q at QMGR2.
They then wait for a response on a reply queue on QMGR1.
If QMGR2 doesn't respond within 5 seconds we want them to time out and be told that they will be emailed the response.
Then I want the messages that didn't arrive in time to somehow end up on another queue which will then get the message and email it to the user.
My question is - what is the best way to ensure the messages that didn't arrive in time (and hence nothing is waiting to do a get on them) get to the email queue ?
Thanks,
TC. |
|
| Back to top |
|
 |
| bduncan |
| Posted: Mon Jul 15, 2002 10:43 am Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
I don't think there's any easy way to do this, but here's one possibility. Your application will have a 5 second wait time when waiting for the reply message (which I'm assuming you are matching against msgid, correlid, or some combination of the two...) At this point your application informs the user they'll get an email shortly. Now you basically have an orphaned message (when it does finally arrive) that will never get picked up. To process it, you'll need a second application. This application will browse the queue, and each message it browses, it will look at the put time. Assuming the clocks on the two machines are synched, your application simply checks to see if the puttime is more than 5 seconds in the past. If this is the case, it does an MQGET without browse, providing the msgid of the message it just browsed. This will return the message, and the application can then process it, or move it to some other queue for processing later.
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| nimconsult |
| Posted: Mon Jul 15, 2002 10:09 pm Post subject: |
|
|
Master
Joined: 22 May 2002
Posts: 268
Location: NIMCONSULT - Belgium
|
A variation on Brandon's suggestion:
After the 5 seconds time-out, the client application posts a message on a second queue (q.timed.out), containing the "correlation id" of the expected reply. A second application reads the messages from the second queue (q.timed.out), and reads the original reply queue using the correlation id.
Advantages:
- under normal conditions (no stress) nothing will be posted on the second queue (q.timed.out), the second application has nothing to do and introduces no overhead on the system.
- no problem of clock synch.
_________________
Nicolas Maréchal
Senior Architect - Partner
NIMCONSULT Software Architecture Services (Belgium)
http://www.nimconsult.be |
|
| Back to top |
|
|
| timcl |
| Posted: Mon Jul 15, 2002 10:26 pm Post subject: |
|
|
Novice
Joined: 16 May 2001
Posts: 23
Location: Australia
|
Thanks guys. I have found a solution that seems to work.
I did some more research on this site and found someone who was trying to do something similar and "sdpls" suggested doing a put from QMGR2 with an expiry of 5 seconds and MQRO_EXCEPTION_WITH_FULL_DATA and a reply_to_q of the email_q and reply_to_qmgr of QMGR1.
(See : http://www.mqseries.net/phpBB2/viewtopic.php?t=2636 )
This will then automatically re-route the orphaned messages to the email q if they are not picked up within 5 seconds. I tested this and it works OK.
My only problem now is that QMGR2 is on OS/390 MQ v5.2 which doesn't support MQRO_EXCEPTION_WITH_FULL_DATA  . So until I install v5.3 on OS/390 I will have to have an intermediate q on QMGR1 which will do a GET then a put with MQRO_EXCEPTION_WITH_FULL_DATA and pass it onto the destination q. |
|
| Back to top |
|
|
| nimconsult |
| Posted: Tue Jul 16, 2002 3:18 am Post subject: |
|
|
Master
Joined: 22 May 2002
Posts: 268
Location: NIMCONSULT - Belgium
|
That sounds easy, but in fact it will not work if you don't take care. Let me try to explain why.
First trivial point: the report option is MQRO_EXPIRATION_WITH_FULL_DATA and not MQRO_EXCEPTION_WITH_FULL_DATA.
Second point (more important, but hard to explain)
The report message is not produced when the message expires, but when the message is discarded from the queue.
First consequence: there may be a long interval of time between the expiration of the message and the time when the message is actually discarded from the queue. In your instance this might be unimportant because your objective is to send an e-mail and delivery time of e-mails is far from being predictible.
Second consequence: you have to make sure that "something happens" that makes your message disappear from the queue (and by consequence send a report message).
The question is: what makes an expired message be discarded from the queue?
In "MQ Series Application pogramming reference" you read
| Quote: |
In the current implementations, the message is discarded when
a browse or nonbrowse MQGET call occurs that would have returned the message had it not already expired. |
Do you start feeling the problem? In a typical request-reply scenario, the application reads the reply messages with MQMO_MATCH_CORREL_ID set. If this is your case, the expired message will never be elected for retrieval by a client application, so it will never be discarded, so the report will never be generated.
Try this with the API exerciser:
- Open Q1 in output mode
- Put M1, with correlation id AAAAAAAAAAAAAAAAAAAAAAAA, expiry 1 second, MQRO_EXPIRATION_WITH_FULL_DATA.
- Put M2, with correlation id BBBBBBBBBBBBBBBBBBBBBBBB, no expiry
- Close Q1
- At this point the current depth of Q1 is 2
- Open Q1 in input mode
- Get, with MQMO_MATCH_CORREL_ID, and correl id BBBBBBBBBBBBBBBBBBBBBBBB. This retrieves M2.
- Close Q1
- At this point the current depth of Q1 is 1. The expired message was not discarded and no report message was generated!
- Browse the queue with MQ Series explorer. The queue is empty! The browse action has discarded the message and the report message was generated.
Conclusion: to quote an earlier post, there is no easy way to achieve your objective. If you do not implement a second process as suggested earlier, make sure you understand the above description.
_________________
Nicolas Maréchal
Senior Architect - Partner
NIMCONSULT Software Architecture Services (Belgium)
http://www.nimconsult.be |
|
| Back to top |
|
|
| timcl |
| Posted: Tue Jul 16, 2002 9:16 pm Post subject: |
|
|
Novice
Joined: 16 May 2001
Posts: 23
Location: Australia
|
Thanks for the note to take care about when an expiry report will be generated.
I think if we go with that method we will just have a "message expirer" house-keeping process that will do a browse of the messages every so often.
I have also put forward your q.timed.out suggestion as a good alternative.
Cheers. |
|
| 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
|
|
|
|
