| Author |
Message
|
| mqla |
 Posted: Thu May 30, 2002 11:19 am Post subject: Report messages not delivered immediately |
 |
|
Novice
Joined: 17 Apr 2002
Posts: 10
|
Our QMgr is on Win NT. When we send a message to remote Q with expiry time and the messages expires while in the XMIT queue, we are expecting a report message in reply to Q.
For some reason those report message are accumulated some where and delivering messages after we browse the XMIT and Reply to Q.
From the MQSeries documentation I could not find any option for immediate delivery of report messages.
Does any one see this problem before. Please suggest me documentation related to this.
Thanks in advance. |
|
| Back to top |
|
 |
| mrlinux |
| Posted: Thu May 30, 2002 11:29 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
Well MQSeries doesnt expire messages by just the expire time. They require the expire time and a MQGET is done then message will be expired.
in other words there will look like messages are there (depth) until you look and then they will expire and disppear and generate report messages.
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| mqonnet |
| Posted: Thu May 30, 2002 11:33 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
When you do a browse get, the messages that are expired are removed off the queue and if a report was requested, one would be generated for you. Just having expiry set on a put does not help you achieve expiration report messages.
Cheers.
Kumar
_________________
IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator |
|
| Back to top |
|
|
| mqla |
| Posted: Thu May 30, 2002 11:44 am Post subject: |
|
|
Novice
Joined: 17 Apr 2002
Posts: 10
|
Kumar,
when messages are expiring in my transmission queue, do I need to browse get the XMIT queue periodically to receive expiry messages ?
I am sorry if I a missing something.
Thanks |
|
| Back to top |
|
|
| mqonnet |
| Posted: Thu May 30, 2002 12:12 pm Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
Well XMITQ does not live in isolation. Either it is serviced by an MCA or a trigger monitor. And since both of them would be doing a get, you get the expiration report generated. But if you dont have anything looking at the Xmitq, then it is a simple case of a regular pre-defined queue which needs a get(browse/destructive) for the expiration report to be generated.
Cheers.
Kumar
_________________
IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator |
|
| Back to top |
|
|
| mqla |
| Posted: Thu May 30, 2002 1:47 pm Post subject: |
|
|
Novice
Joined: 17 Apr 2002
Posts: 10
|
Kumar,
Thanks for the reply. When the channel is in inactive state, will MCA tries to do a get on the Xmit queue or will it do a get only after the channel becomes active ?
My observation is MCA is not making a get call when channel is down. |
|
| Back to top |
|
|
| StefanSievert |
| Posted: Thu May 30, 2002 3:50 pm Post subject: |
|
|
Partisan
Joined: 28 Oct 2001
Posts: 333
Location: San Francisco
|
| mqla wrote: |
Kumar,
Thanks for the reply. When the channel is in inactive state, will MCA tries to do a get on the Xmit queue or will it do a get only after the channel becomes active ?
My observation is MCA is not making a get call when channel is down. |
Consider the MCA as being just another MQ application. If it is not running, it won't make a get call. A channel will never be in anything else but INACTIVE or STOPPED state, if the (initiating) MCA process is not running.
Are you trying to use expiration reports as a means to detect an inactive channel? If not, why are you worried about not getting the expiry reports in real-time? Usually, channels are triggered and active if there are messages available for transmission on the XMITQ so expiry reports shouldn't occur in the first place or be delivered right away. The time to start up a channel should be considered when defining expiry intervals.
I am trying to understand your requirements. Why it is a problem for you if expiry reports are delayed.
Can you clarify what you are trying to achieve?
Stefan
BTW, Kumar, under what circumstances would you have a Trigger Monitor watching an XMITQ? 
_________________
Stefan Sievert
IBM Certified * WebSphere MQ |
|
| Back to top |
|
|
| mqla |
| Posted: Thu May 30, 2002 4:32 pm Post subject: |
|
|
Novice
Joined: 17 Apr 2002
Posts: 10
|
I want the expiry reports in realtime because I need to take further actions based on the message delivery. If message expires in my transmission queue and could not be transitted to destination, then I need to notify the reason to different people at different locations through our backbone communication lines. Information I send is time critical.
I think to overcome this kind of problems, I should write a program to closely monitor the channel status and do a browse on the XMit queue so that report messages are delivered. Any Suggestions ? |
|
| Back to top |
|
|
| StefanSievert |
| Posted: Thu May 30, 2002 5:13 pm Post subject: |
|
|
Partisan
Joined: 28 Oct 2001
Posts: 333
Location: San Francisco
|
| mqla wrote: |
I want the expiry reports in realtime because I need to take further actions based on the message delivery. If message expires in my transmission queue and could not be transitted to destination, then I need to notify the reason to different people at different locations through our backbone communication lines. Information I send is time critical.
I think to overcome this kind of problems, I should write a program to closely monitor the channel status and do a browse on the XMit queue so that report messages are delivered. Any Suggestions ? |
Hmm, let's see. Two questions upfront:
1/ What does 'message delivery' mean to you? Does it mean that the message has reached the target queue? Or does it mean that the receiving application has sucessfully processed it?
2/ Is the information you send really void after your 'expiry' interval has elapsed? Or do you need to know that there is a 'delay' of sorts?
Principally you are in trouble, because of the asynchronous nature of MQ. You can, for example use delivery reports (MQRO_COD). The target queue manager will generate this report message upon successfull delivery of the message to an application, meaning a destructive (commited) MQGET. Now, everything is fine applicationwise, right? But what if the channel back to the sending system is not up? In this case you won't get the positive COD report, even if processing of the message was successfull. The same is true for arrival reports (MQRO_COA), which will tell you that the message has been successfully put onto the final destination queue. And then there are exceptions... What if the message ends up on the dead-letter queue? How do you handle this?
You probably need a combination of both, a report message and channel monitoring. Usually, monitoring of the infrastructure is done by system management tools that are built for this exact purpose.
If you can rely on your infrastructure as being operational and on the message delivery of MQ as being guaranteed, application design becomes much easier. A successfull MQPUT then can put you at ease that the message will make it in near-realtime. Failure of any system components will be detected and cured by systems management.
Bottom line: I would clearly separate infrastructure exception handling from application exception handling. How you best do that in your special situation is depending on the answers to my two questions above.
Does this make any sense?
Stefan
_________________
Stefan Sievert
IBM Certified * WebSphere MQ |
|
| Back to top |
|
|
| mqla |
| Posted: Thu May 30, 2002 9:38 pm Post subject: |
|
|
Novice
Joined: 17 Apr 2002
Posts: 10
|
Thank you stefen for you analysis.
First let me answer your questions.
>>1/ What does 'message delivery' mean to you? Does it mean that the message has reached the target queue? Or does it mean that the receiving application has sucessfully processed it?
I mean message has been successfully processed by the receving application.
>>2/ Is the information you send really void after your 'expiry' interval has elapsed? Or do you need to know that there is a 'delay' of sorts?
Information I send after expiry time is void and in the event of delay I need to mark that information in my database as void and I should not use the data in future and alert some other systems about the same. For this reason I should get the delay information as quickly as possible.
You are right when the channel from other end to my side is down, I will not get the report message immediately. If message ends in Dead Letter queues on either side we have triggers setup to process those messages. I am more worried about the problems on my side 
I agree that it is better to separate infrastructure exceptions from applications infrastructure. We are trying to find out more about Candle for monitoring the infrasture but I believe it will take few more months before implementation. Mean while I should have my own channel monitor program.
Do you think report messages are sent in near realtime if my program periodically browse transmission queue when server channel on my side becomes inactive ? Even if I know that my server channel is in inactive state, I can't activate it. My server channel can only be activated by requester channel because server channel is not fully qualified. Please let me know if you have any other better solutions. |
|
| Back to top |
|
|
| mqonnet |
| Posted: Fri May 31, 2002 5:30 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
One of the alternatives would be as you pointed out to have a program monitor the xmitq doing a browse.
This i would say is one of the drawbacks of MQ on all platforms except Tandem. Because on Tandem, the expiry is done automatically after the message expires. And hence it is no more the responsibility of the app developer to take care of the message that has expired and still hanging around the queue.
Stefan, thanks for pointing me out. Please ignore my statement on Trigger mon.
Cheers.
Kumar
_________________
IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator |
|
| Back to top |
|
|
| mqla |
| Posted: Fri May 31, 2002 8:56 am Post subject: |
|
|
Novice
Joined: 17 Apr 2002
Posts: 10
|
Thanks for the replies.
I want to monitor channel status through a program or a script. What are the options we have for doing this ? Are there any built in MQSeries programs for doing this ? Can you please send me the helpful links for this task ? |
|
| Back to top |
|
|
| mrlinux |
| Posted: Fri May 31, 2002 9:23 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
Well if you want cheap and dirty here is a script command to do that
echo "dis chs(*) status" | runmqsc QMGR_NAME > file.out
cat file.out | grep -v RUNNING | grep CHANNEL > notRunning.list
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| StefanSievert |
| Posted: Fri May 31, 2002 1:08 pm Post subject: |
|
|
Partisan
Joined: 28 Oct 2001
Posts: 333
Location: San Francisco
|
| mqla wrote: |
Thanks for the replies.
I want to monitor channel status through a program or a script. What are the options we have for doing this ? Are there any built in MQSeries programs for doing this ? Can you please send me the helpful links for this task ? |
Monitoring (browsing) of the XMITQ will probably cause other problems, because the MCA wants to have exclusive access to the queue. So either your monitoring program abends with a 2042 when the channel is running (which you could interpret as 'everything's fine') or, much worse, your channel is not able to start because your monitoring program has the queue open for input.
So, you could use a script as Jeff pointed out. Or you could turn on channel events and monitor the SYSTEM.ADMIN.CHANNEL.EVENT queue for START/STOP messages pertaining to your channel using a triggered program on that queue. If you detect a stopped channel, you could then start your browsing application to generate the expiry reports for all messages on the XMITQ. Or, you could use PCF messages to periodically inquire bout the channel status.
A (hopefully) helpful link would be the MQSeries Programmable System Management manual.
Do you have the option to change the SERVER/REQUESTER channel pair into a SENDER/REQUESTER pair? This way you could start the channel from both ends and probably avoid a lot of pain...
Have a nice weekend,
Stefan
_________________
Stefan Sievert
IBM Certified * WebSphere MQ |
|
| Back to top |
|
|
| mqla |
| Posted: Fri May 31, 2002 1:26 pm Post subject: |
|
|
Novice
Joined: 17 Apr 2002
Posts: 10
|
Thanks Jeff and Stefan. I would use PCF commands to check the status of the channel before opening the XMIT queue for browsing.
BTW, I can't change the channel pair to sender/requester.
Have a nice weekend. |
|
| Back to top |
|
|
|
|
