| Author |
Message
|
| Lillian |
 Posted: Thu Apr 14, 2005 7:59 am Post subject: MQMD COD report option |
 |
|
Centurion
Joined: 15 Apr 2002
Posts: 102
|
Hi All - using mqv5.3
I am trying to understand the workings on the report options set on a messages, specifically the generation of the confirmation on delivery. I have been doing some performance measurement on an application and it seems that ,there is an overhead on the application when COD is required. the application does a get off the queue and puts on a reply queue.
-The data seems to imply that the COD is only generated after the put and not the get, Why?
- at what point does the QM generated the COD
- would a browse generate a COD?
Another observation is the variation is much higher when processing a bulk of messages sitting on teh queue as opposed to one msg / sec.
Why would the interval between messages be a factor?
any reference/doc to the COD mechanism would be appreciated. |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Thu Apr 14, 2005 10:11 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Quote: |
The data seems to imply that the COD is only generated after the put and not the get, Why?
|
???? What data? A COD is generated by the QM when an application MQGETs the message off of the queue. Nothing to do with an MQPUT.
| Quote: |
any reference/doc to the COD mechanism would be appreciated.
|
Application Programming Guide Manual
Application Programming Referance Manual
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bob_buxton |
| Posted: Thu Apr 14, 2005 12:16 pm Post subject: |
|
|
Master
Joined: 23 Aug 2001
Posts: 266
Location: England
|
If you get within syncpoint the COD message and your reply message will also be in syncpoint so the COD and reply will both become available at syncpoint time rather than at Get time.
_________________
Bob Buxton
Ex-Websphere MQ Development |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Thu Apr 14, 2005 12:25 pm Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
Peter
I thought that a COA was raised on the MQGET, but COD was raised when the queue manager put the message on the target queue?
(note...not the MQPUT by the application, but the MQPUT by the queue manager to the target queue)
I could be wrong (usually am) and stand to be corrected but that was my understanding of how it worked. |
|
| Back to top |
|
|
| bob_buxton |
| Posted: Thu Apr 14, 2005 12:56 pm Post subject: |
|
|
Master
Joined: 23 Aug 2001
Posts: 266
Location: England
|
MQRO_COA
Confirm-on-arrival reports required.
This type of report is generated by the queue manager that owns the destination queue, when the message is placed on the destination queue. Message data from the original message is not included with the report message.
If the message is put as part of a unit of work, and the destination queue is a local queue, the COA report message generated by the queue manager becomes available for retrieval only if and when the unit of work is committed.
A COA report is not generated if the Format field in the message descriptor is MQFMT_XMIT_Q_HEADER or MQFMT_DEAD_LETTER_HEADER. This prevents a COA report being generated if the message is put on a transmission queue, or is undeliverable and put on a dead-letter queue.
MQRO_COD
Confirm-on-delivery reports required.
This type of report is generated by the queue manager when an application retrieves the message from the destination queue in a way that causes the message to be deleted from the queue. Message data from the original message is not included with the report message.
If the message is retrieved as part of a unit of work, the report message is generated within the same unit of work, so that the report is not available until the unit of work is committed. If the unit of work is backed out, the report is not sent.
A COD report is not always generated if a message is retrieved with the MQGMO_MARK_SKIP_BACKOUT option. If the primary unit of work is backed out but the secondary unit of work is committed, the message is removed from the queue, but a COD report is not generated.
A COD report is not generated if the Format field in the message descriptor is MQFMT_DEAD_LETTER_HEADER. This prevents a COD report being generated if the message is undeliverable and put on a dead-letter queue.
MQRO_COD is not valid if the destination queue is an XCF queue.
_________________
Bob Buxton
Ex-Websphere MQ Development |
|
| Back to top |
|
|
| JT |
| Posted: Thu Apr 14, 2005 2:26 pm Post subject: |
|
|
Padawan
Joined: 27 Mar 2003
Posts: 1564
Location: Hartford, CT.
|
| lillian wrote: |
| - would a browse generate a COD? |
No. The message has to be deleted from the queue (destructive 'get') before the COD message is generated.
To verify bob b.'s statement, change the MQGET call to include the option 'MQGMO_NO_SYNCPOINT '. The COD should be generated immediately. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Apr 14, 2005 3:18 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| kevinf2349 wrote: |
Peter
I thought that a COA was raised on the MQGET, but COD was raised when the queue manager put the message on the target queue?
(note...not the MQPUT by the application, but the MQPUT by the queue manager to the target queue)
I could be wrong (usually am) and stand to be corrected but that was my understanding of how it worked. |
Bob's quote is the official word, but in short:
The COA comes out when the receiver MCA succesfully MQPUTs to the destination queue.
The COD comes out when an application successfully MQGET's the message from the queue.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Apr 14, 2005 7:07 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Now of course if the destination qmgr is the local qmgr ...
the COA would be created at put time.....
Enjoy  |
|
| Back to top |
|
|
| Lillian |
| Posted: Thu Apr 14, 2005 11:56 pm Post subject: |
|
|
Centurion
Joined: 15 Apr 2002
Posts: 102
|
Is there a way of seperating the application from the COD generation such that the applications performance is not "affected"? It seems that an overhead should be expected since the QM is common to both processes?
If this overhead is not acceptable, is there another way of keeping track of processed messages? |
|
| Back to top |
|
|
| Nigelg |
| Posted: Fri Apr 15, 2005 2:35 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
For goodness sake...
If you want a COD, you have to accept that some cycles have to be allocated to write it.
If you do not want to use those cycles, don't ask for a COD.
You never get something for nothing. |
|
| Back to top |
|
|
|
|
