| Author |
Message
|
| Eric Koontz |
 Posted: Fri Feb 04, 2005 2:20 pm Post subject: Message logging |
 |
|
Newbie
Joined: 01 Mar 2004
Posts: 6
|
I am researching methods by which I can implement better logging/tracking for our MQ messages.
I need to be able to verify that a particular asyncronous MQID was delivered, and I have no ability to require that the party on the other side ACK the message.
Thanks in advance for suggestions. |
|
| Back to top |
|
 |
| csmith28 |
| Posted: Fri Feb 04, 2005 2:46 pm Post subject: |
|
|
Grand Master
Joined: 15 Jul 2003
Posts: 1196
Location: Arizona
|
Delivered from?......
Delivered to?.....
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
| Back to top |
|
|
| Eric Koontz |
| Posted: Fri Feb 04, 2005 3:12 pm Post subject: message logging |
|
|
Newbie
Joined: 01 Mar 2004
Posts: 6
|
| a local process specifies a remote queue for delivery which then specifies xmit queue and a destination queue on a remote Q Manager that we have no ability to specify a confirmation of arrival on. We would like to be able to get a COA, but cannot rely on the other side to implement this feature. |
|
| Back to top |
|
|
| JT |
| Posted: Fri Feb 04, 2005 3:13 pm Post subject: |
|
|
Padawan
Joined: 27 Mar 2003
Posts: 1564
Location: Hartford, CT.
|
Have you considered using Report messages, with the COA or COD option:
- A confirmation of arrival (COA) report message indicates that the message has arrived on the target queue.
- A confirmation of delivery (COD) report message goes one step further, and indicates that the message has been consumed by the target application.
- Both types of Report messages are generated by the target queue manager, and not the target application.
So, with certain types of Report messages (COA & COD ), there's no burden on the target application, the configuration is the sender's responsibility, and the generation of the Report message falls within the domain of the target queue manger. |
|
| Back to top |
|
|
| csmith28 |
| Posted: Fri Feb 04, 2005 3:22 pm Post subject: |
|
|
Grand Master
Joined: 15 Jul 2003
Posts: 1196
Location: Arizona
|
What JT said and...
The Persistence Feature of WMQSeries was partially designed to eliminate the need for such auditing.
Confirm that the value of DEFPSIST is (YES) on your XMITQ and read up on Persistence in the WMQ Systems Administration Guide.
If you like you can also specify DEFPSIST(YES) on your QRemote definition and in the MQMessage Discriptor.
I believe the application has the final say, if it defines the message non-persistent in the Message Descriptor it will overrule the value of DEFPSIST on the Queue's.
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
| Back to top |
|
|
| JT |
| Posted: Fri Feb 04, 2005 3:29 pm Post subject: |
|
|
Padawan
Joined: 27 Mar 2003
Posts: 1564
Location: Hartford, CT.
|
| Quote: |
| We would like to be able to get a COA, but cannot rely on the other side to implement this feature. |
The feature is available 'out of the box' on the target queue manager. The only practical requirement of the target destination is a path back to your application (i.e. reply-to-queue). |
|
| Back to top |
|
|
| EddieA |
| Posted: Fri Feb 04, 2005 4:17 pm Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
| Quote: |
| Confirm that the value of DEFPSIST is (YES) on your XMITQ |
Complete waste of time, and does nothing.
| Quote: |
| specify DEFPSIST(YES) on your QRemote definition |
Getting better, but this only works if the PUT uses the option to take Persistence from the Queue.
| Quote: |
| in the MQMessage Discriptor |
Bingo. That's the safest way, and is usually considered Best Practise.
| Quote: |
| the application has the final say |
Absolutely correct. The application can set one of 3 values: Persistent, non-persistent, and (the default) take the value from the queue.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| EddieA |
| Posted: Fri Feb 04, 2005 4:19 pm Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
| Quote: |
| The only practical requirement of the target destination is a path back to your application |
And the correct authorisations to do this.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| csmith28 |
| Posted: Fri Feb 04, 2005 4:25 pm Post subject: |
|
|
Grand Master
Joined: 15 Jul 2003
Posts: 1196
Location: Arizona
|
| EddieA wrote: |
| Quote: |
| Confirm that the value of DEFPSIST is (YES) on your XMITQ |
Complete waste of time, and does nothing.
| Quote: |
| specify DEFPSIST(YES) on your QRemote definition |
Getting better, but this only works if the PUT uses the option to take Persistence from the Queue.
| Quote: |
| in the MQMessage Discriptor |
Bingo. That's the safest way, and is usually considered Best Practise.
| Quote: |
| the application has the final say |
Absolutely correct. The application can set one of 3 values: Persistent, non-persistent, and (the default) take the value from the queue.
Cheers, |
So actually all three are true if the MQMD takes the value from the queue like I said or are you trying to say that if the message has "take the value of the queue" set and it hits a QRemote that has DEFPSIST(NO) then it gets sent to an XMITQ that has DEFPSIST(YES) the message will be treated as not persistent?
Is that what you are saying?
I was under the impression that if the orginal MQMD was set to default "take the value of the queue" it would get to the QRemote that was set to DEFPSIST(NO) that QRemote would add it's MQMD with that value but when it gets to the XMITQ it would add it's MQMD with the value of DEFPSIST(YES). Then the message would be treated as Persistent.
But then, if the application that created the original message specified Persistent or non-Persistent the value of DEFPSIST on the QRemot and the XMITQ will be over-ridden regardless.
Or does the value of DEFPSIST on a QRemote overrule the value of DEFPSIST on an XMITQ?
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
| Back to top |
|
|
| EddieA |
| Posted: Fri Feb 04, 2005 5:09 pm Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
| Quote: |
| hits a QRemote that has DEFPSIST(NO) then it gets sent to an XMITQ that has DEFPSIST(YES) the message will be treated as not persistent? |
Absolutely.
The message takes the persistence from the Queue it's originally put to. From that point on, the message retains the same persistence, no matter what any intermediate queues are defined as.
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| csmith28 |
| Posted: Fri Feb 04, 2005 5:37 pm Post subject: |
|
|
Grand Master
Joined: 15 Jul 2003
Posts: 1196
Location: Arizona
|
| Quote: |
| The message takes the persistence from the Queue it's originally put to. |
Unless the Application specifies persistence no or yes.
Ok, I believe you but I never really thought of an XMITQ as being intermediate. XMITQ's are IMHO a Keystone object that should override the Values of a QRemote or a QAlias. But that is just me.
Thanks for the clarification.
IMHO the persistence thing has been convoluted beyond reason.
YES is NO. NO is YES. YES and NO is Maybe unless the Application specifies YES or NO.....
Like I said before in another thread. If the application has ultimate authority over persistence why bother having a DEFPSIST attribute at the Queue level at all?
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
| Back to top |
|
|
| EddieA |
| Posted: Sat Feb 05, 2005 12:58 am Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
| Quote: |
| The message takes the persistence from the Queue it's originally put to |
This was only the answer to your question:
| Quote: |
| if the message has "take the value of the queue" set and it hits a QRemote that has DEFPSIST(NO) then it gets sent to an XMITQ that has DEFPSIST(YES) the message will be treated as not persistent |
Not the be all, and end all, of how persistence is defined. I thought I'd answered that in my previous post.
| Quote: |
| If the application has ultimate authority over persistence why bother having a DEFPSIST attribute at the Queue level at all |
I would have prefered that it work that way from the beginning. But it's too late to change it now. Oh, and persistence isn't the only attribute that I wish had to be enforced at the application level. Leaving it to the queue leads to waaaaaay too many problems down the road.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Feb 05, 2005 1:32 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
The defpersist attribute of the xmitq only comes into play in following case:
The queue manager is accessing a queue on the remote qmgr for put and will put it on the xmitq for this qmgr (default routing, reply to queue, etc...)
As no remote queue is specified the message will take the persistency of the xmitq if persistency mode qdef is used.
Enjoy  |
|
| Back to top |
|
|
| Eric Koontz |
| Posted: Mon Feb 07, 2005 1:22 pm Post subject: in regards to the COA/COD report |
|
|
Newbie
Joined: 01 Mar 2004
Posts: 6
|
I have now configured for a COA report - set the MQMD report value to MQRO_COA, created a reply to queue and specified the Q and QMgr in the MQMD - seems simple, yet I do not receive a message in my reply Q.
Does the destination Q Manager have to be configured to reply? |
|
| Back to top |
|
|
| EddieA |
| Posted: Mon Feb 07, 2005 1:29 pm Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
| EddieA wrote: |
| Quote: |
| The only practical requirement of the target destination is a path back to your application |
And the correct authorisations to do this. |
Look in the destination QM's DLQ.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
|
|
