| Author |
Message
|
| peterw686 |
 Posted: Fri Apr 30, 2004 12:37 pm Post subject: question for SYSTEM.CLUSTER.TRANSMIT.QUEUE |
 |
|
Acolyte
Joined: 26 Sep 2002
Posts: 73
|
Hi All,
I know for the cluster, it will send the message via the SYSTEM.CLUSTER.TRANSMIT.QUEUE. Something I don't understand is how it behaviours under the such situation:
The status of target cluster QM is "BINDING". When I sent messages to the cluster queue hosted on that QM, it didn't complain and I found the messages were stayed in the SYSTEM.CLUSTER.TRANSMIT.QUEUE. In this case, my program couldn't get the reply messages.
How the SYSTEM.CLUSTER.TRANSMIT.QUEUE and the cluster work in such situation? Is there any way to notice such situation from the programming perspective view?
Thanks in advance.
Peter |
|
| Back to top |
|
 |
| Missam |
| Posted: Mon May 10, 2004 11:54 am Post subject: |
|
|
Chevalier
Joined: 16 Oct 2003
Posts: 424
|
QM don't complain of the status Binding.because its just a state not an error condition of the channel.the next states are requsting and then running.messages will remain on XMITQ until the status become running.
More over how long you channel remaining in Binding State..? |
|
| Back to top |
|
|
| peterw686 |
| Posted: Tue May 11, 2004 10:23 am Post subject: |
|
|
Acolyte
Joined: 26 Sep 2002
Posts: 73
|
Thanks.
The time for "Binding state" is varies, sometimes it's half an hour, sometimes it could be one day long.
Our problem is there is a time requirement for getting response back. If it stays in the Transmition queue, we can't get the response back on time. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue May 11, 2004 10:49 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
In this situation, there is no difference as far as your application is concerned between putting to a cluster queue and putting to a remote queue definition.
If the channel from your queue manager to the remote queue manager is not working, your message will sit on a transmission queue somewhere.
In order for your application to know that a message is sitting on a transmission queue, you would have to code your application to act as a monitor for WebSphere MQ in addition to it's normal application duties.
This is usually considered as a less than good practice. If you need to monitor your channels, write or buy an application to monitor your channels.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| JT |
| Posted: Wed May 12, 2004 12:56 pm Post subject: |
|
|
Padawan
Joined: 27 Mar 2003
Posts: 1564
Location: Hartford, CT.
|
| peterw686 wrote: |
| Is there any way to notice such situation from the programming perspective view? |
Don't know if it's practical, but you could request a report message confirming the arrival of the original message (COA). If a confirmation isn't received by the sending program within a specified time period, resend the message to another queue manager in the cluster. |
|
| Back to top |
|
|
| mqonnet |
| Posted: Wed May 12, 2004 1:16 pm Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
"Our problem is there is a time requirement for getting response back. If it stays in the Transmition queue, we can't get the response back on time."
---Set expiry on the message. May be even with report.
In your app code your get to wait as long/less/more as you have set your expiry on your put. That way you know that the message must be processed within a certain period of time. Which you can figure out on the various factors affecting your system(design). If you dont get a response, consider the message to be expired and reissue the request.
Of course there are host of considerations when you use this method that you need to take care of. :)
Just my 2Cents.
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 |
|
|
| EddieA |
| Posted: Wed May 12, 2004 1:31 pm Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
| Quote: |
| ---Set expiry on the message. May be even with report. |
The "problem" with this approach is that the Report message is NOT generated at the time the message actually expires. It is generated when the message is "read", and at that point MQ decides it's expired, discards the message, and sends the Report.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| mqonnet |
| Posted: Wed May 12, 2004 1:37 pm Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
You are right, Eddie. And thats the reason i have stressed on the need to handle the timeout within the app by coding the reasonably calculated value on the GET.
You may want the reports at the EOD to sum up how many requests did not get replies and who were they.
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 |
|
|
| PeterPotkay |
| Posted: Wed May 12, 2004 5:15 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
The original question was:
| Quote: |
How the SYSTEM.CLUSTER.TRANSMIT.QUEUE and the cluster work in such situation? Is there any way to notice such situation from the programming perspective view?
|
So, is Peter asking "How do I write A program to notice this?" Or is he asking "How do I change MY (application) program to notice this?"
For the first question, easy enough you write a program that issues PCF commands to the QMs to find out the channel statuses. Or if you don't feel like reinventing the wheel, you use a commercially available product that already does this.
For the second question, that is getting into fuzzy territory. A putting application shouldn't care what is happening down stream. If the MQPUT worked, then know MQ has your message and the reply will come back. Eventually. MQ never made any promises on how fast it will deliver a message. It only assures that it will eventually. Changing your application to inquire on channel statuses before you put a message will hurt performance. And then if you are going to start hard coding QM names in your MQOPENs, why bother using clustering. Now you are doing all the work.
No, I think the best solution is to use a separate tool to monitor the depth of the XMIT queue, and page people if it stays above x for x seconds. As for your app, if it is an Inquiry, just resubmit it, and hope that the algorithim round robins it to another QM, hopefully with a live channel going to it. If the message cannot be duplicated (DB inserts?), then code the sending app to handle the fact that the reply may not come back immediatly.
Better yet, if your cluster channels are having this many problems (what version are you at? 5.3 I hope!), your network stinks. In this case define a second set of cluster channels using another protocal, like LU62, and give one set of channels (either the TCP or LU62) the higher priority. The other will act as a back up.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| peterw686 |
| Posted: Thu May 13, 2004 11:18 am Post subject: |
|
|
Acolyte
Joined: 26 Sep 2002
Posts: 73
|
Thanks all.
I will provide these options as you guys suggested to my manager.
I think one major reason they wanna cluster is for the redundancy, however it looks like a difficulty here. |
|
| Back to top |
|
|
|
|
