| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| mirrorq and amqsaxe MQPMO Options MQPMO_NEW_MSG_ID |
« View previous topic :: View next topic » |
| Author |
Message
|
| mvic |
 Posted: Fri Jun 03, 2011 11:21 am Post subject: |
 |
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| hal wrote: |
| The "New message ID" option is not set in any of my output nodes and the behavior is as expected. |
I don't understand how this relates to the API exit problem you identified. Is it related? |
|
| Back to top |
|
 |
| mvic |
| Posted: Fri Jun 03, 2011 11:24 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| hal wrote: |
| Anyway, WebSphere MQ 7 pub/sub and API exits both degrade MsgId message tracking serviceability. |
I think you have demonstrated how things looked different in your API exit; it might be a bug in MQ, I would guess. But I didn't see any pub/sub angle to this problem.. can you go into any more details about the references you are making to pub/sub? |
|
| Back to top |
|
|
| hal |
| Posted: Fri Jun 03, 2011 12:07 pm Post subject: |
|
|
Acolyte
Joined: 07 Dec 2005
Posts: 67
Location: New York City, New York
|
To repeat:
| Quote: |
| I have also observed that the pub/sub mirrorq "replacement" described at http://www.mqseries.net/phpBB2/viewtopic.php?t=51319 does not clone MsgIds. Try changing the queue that an MQPUT application uses into an alias queue which points to a topic by following that procedure. You will see that the MsgId values in the original and mirrored queues (Q1 and Q2) are different. |
Since pub/sub is new to WebSphere MQ 7, the generation of different MsgIds cannot be attributed to a behavioral change. Perhaps it is by design. I am merely saying that pub/sub cannot be used to accurately track messages by MsgIds as messages flow from queue manager to queue manager. |
|
| Back to top |
|
|
| mvic |
| Posted: Fri Jun 03, 2011 12:23 pm Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| hal wrote: |
| Since pub/sub is new to WebSphere MQ 7, the generation of different MsgIds cannot be attributed to a behavioral change. |
Pub/sub has been in MQ for years (v6, v5.3, at least).
| Quote: |
| Perhaps it is by design. |
It's possible I am at fault, and it is clear to everyone else, but what exactly is the problem with generation of msgids in pub/sub?
| Quote: |
| I am merely saying that pub/sub cannot be used to accurately track messages by MsgIds as messages flow from queue manager to queue manager. |
I have still failed to notice where this has been demonstrated. I even read the thread you mentioned and still do not see how that discussion substantiates your statement here. |
|
| Back to top |
|
|
| hal |
| Posted: Fri Jun 03, 2011 12:48 pm Post subject: |
|
|
Acolyte
Joined: 07 Dec 2005
Posts: 67
Location: New York City, New York
|
I am referring to the publish/subscribe engine that was migrated from WebSphere Message Broker 6.1 to WebSphere MQ 7. Topic and subscription objects and queue alias topic base types are all new to WebSphere MQ 7. See http://www.websphereusergroup.org/wisconsin/blog/download_file.one?id=29509 and http://publib-b.boulder.ibm.com/abstracts/sg247583.html?Open
Please confirm that you have been able to duplicate the procedure outlined by PeterPotkay's first post in the thread. Compare the MsgIds in Q1 and Q2. Next change the Q2 local queue to a remote queue that points to a local queue (Q3) on another queue manager. Repeat the test and verify that the MsgIds in Q1 and Q3 are different.
I wish to focus on API exits so further pub/sub MsgId discussions are best addressed elsewhere. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Jun 03, 2011 9:33 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20763
Location: LI,NY
|
| mvic wrote: |
| Quote: |
| Perhaps it is by design. |
It's possible I am at fault, and it is clear to everyone else, but what exactly is the problem with generation of msgids in pub/sub?
| Quote: |
| I am merely saying that pub/sub cannot be used to accurately track messages by MsgIds as messages flow from queue manager to queue manager. |
I have still failed to notice where this has been demonstrated. I even read the thread you mentioned and still do not see how that discussion substantiates your statement here. |
I believe that what the op is saying relates to pub/sub vs p2p.
Now in p2p message tracking is usually implemented via msgid and correlId. However in pub/sub you can no longer rely on those and would have to look at user properties on the message.
By design the correlId can be used to identify a subscriber.
By design each message being created should have a different msgid. So when you apply this to pub/sub you have msgid 1 for the msg of the publisher and you have a different msg id for each subscriber receiving this msg.
Like I said, if you want to track a msg throughout it's pub/sub life you'd need to track it by some user properties you set before publishing.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| hal |
| Posted: Mon Jun 06, 2011 9:55 am Post subject: |
|
|
Acolyte
Joined: 07 Dec 2005
Posts: 67
Location: New York City, New York
|
IBM support has responded.
| Quote: |
L3 update:
"There is a genuine defect demonstrated here, but only in the code that
calls the after-put exit. (The behaviour with respect to a new message
ID being chosen is not faulty, as far as I can see. The sample program
amqsput s designed to ask for a new message ID, by specifying MQMI_NONE
in the MsgId field of the MQMD).
The defect is, the After-Put API exit (and MQ trace, as a matter of
fact) shows the MQPMO_NEW_MSG_ID option being present in the
MQPMO.Options after the put, even though MQPMO.Options is an input
field. Because it is an input field, it should not show a change
between before and after the put.
.
This has happened because, at version 7, the queue manager communicates
back to the MQ library code in the application (for the benefit of MQ's
internal processing) that a new message ID had been chosen by the queue
manager. This had been done because MQMD.MsgId supplied to the MQPUT
function was equal to MQMI_NONE. However the information communicated
back to the MQ library code in the application was not intended to be
visible externally.
.
The MQPUT call itself is unaffected, because the MQPMO.Options are
corrected before the MQPUT returns. Thus the "application" code that
called MQPUT does not suffer any confusion because of this defect.
.
I would like to supply a test fix to the customer for their test
systems...on the basis of the notes presented already I believe we can push
forward with an APAR to correct the data being passed to after-put API exit
and trace. Before opening the APAR, however, let's try to ensure that
the test fix does resolve the issue it's intended to resolve..." |
|
|
| Back to top |
|
|
| hal |
| Posted: Wed Jul 06, 2011 8:16 am Post subject: |
|
|
Acolyte
Joined: 07 Dec 2005
Posts: 67
Location: New York City, New York
|
An APAR has been created. The fix will be incorporated into WebSphere MQ 7.0.1.7.
From http://www-01.ibm.com/support/docview.wss?uid=swg1IV02071
| Quote: |
IV02071:
MQPMO.Options contain changed value when the After-Put API exit is called.
But MQPMO.Options should not change during the MQPUT.
APAR status
Closed as program error.
Error description
On entry to the After-Put API exit, MQPMO.Options can contain a
value different from the value on input to MQPUT.
Because MQPMO.Options are an input-only field, this is not
valid.
The MQPMO.Options are corrected before the MQPUT call itself
returns, so applications calling the MQI do not experience this
problem.
The problem is experienced by API exits for After-Put and also
After-Put1. That is, the "after" exits for both MQPUT and
MQPUT1.
If MQ tracing is being used, the MQPMO.Options value dumped in
the MQ trace on return from MQPUT/MQPUT1 can also contain an
incorrect value.
Local fix
Problem summary
****************************************************************
USERS AFFECTED:
Users of After-Put API exits, or users reading MQ trace of the
output data on return from MQPUT.
Platforms affected:
All Distributed (iSeries, all Unix and Windows)
****************************************************************
PROBLEM SUMMARY:
In WebSphere MQ Version 7, the queue manager communicates back
to the WebSphere MQ library code in the application (for the
benefit of internal processing) that a new message ID had been
chosen by the queue manager.
This happens when MQPMO_NEW_MSG_ID is used, or if MQMD.MsgId
supplied to the MQPUT function was equal to MQMI_NONE.
However the information communicated back to the MQ library code
in the application was not intended to be visible externally.
Problem conclusion
WebSphere MQ product code that runs in the application process
has been corrected so the value in MQPMO.Options is unchanged
when presented to the After-Put / After-Put1 API exits and
trace.
---------------------------------------------------------------
The fix is targeted for delivery in the following PTFs:
v7.0
Platform Fix Pack 7.0.1.7
-------- --------------------
Windows U200333
AIX U843721
HP-UX (PA-RISC) U844089
HP-UX (Itanium) U844094
Solaris (SPARC) U844090
Solaris (x86-64) U844096
iSeries tbc_p700_0_1_7
Linux (x86) U844091
Linux (x86-64) U844095
Linux (zSeries) U844092
Linux (Power) U844093
|
|
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
