Hi Jens,
would be really great to get these dumps. I still hope we can make the
Websphere MQ case just work without adding a config option. As we are
setting up a message selector for the message id on receive this
normally should work. If not it must be a speciality of the IBM MQ system.
Christian
Am 05.10.2011 17:18, schrieb Jens:
Hi Christian,
I can get those dumps, too, yes, but it won't work regardless.
With WebSphere MQ you always (!) need to use an "ID:" selector prefix when
working with JMS, or the selector won't match.
Jens
Christian Schneider wrote:
Hi Jens,
that is expected .. at least for the new CXF version. If you specify a
conduitIdSelector then you tell CXF to use that selector when receiving
and to also set a correlation id that matches this pattern.
You have to leave it off too enable message id as correlation id. Can
you also try that and send the messages? I would expect that CXF can
receive and correlate the message if you do not set the conduit config
properties.
So I am curious how the messages look like in this case.
Christian
Am 05.10.2011 13:38, schrieb Jens:
Hi Christian,
it's a synchronous call, but it doesn't work because if you use the
conduitSelector CXF generates its own correlation ID which means the JMS
template will try to use that for correlation instead of the message ID.
Here's a sample message dump.
Request:
MQGET of message number 1
****Message descriptor****
StrucId : 'MD ' Version : 2
Report : 0 MsgType : 1
Expiry : -1 Feedback : 0
Encoding : 273 CodedCharSetId : 1208
Format : 'MQSTR '
Priority : 4 Persistence : 1
MsgId : X'414D5120584E475457303145202020204DFB44A025225A03'
CorrelId : X'3D9F3E81D1AB424BB0BB43D47D231AAF0000000000000002'
BackoutCount : 0
ReplyToQ : 'QA.XN.0000/HMV_VRS_REP.T '
ReplyToQMgr : 'GTW01T '
** Identity Context
UserIdentifier : 'xnhmvc '
ApplIdentityData : ' '
** Origin Context
PutApplType : '28'
PutApplName : 'WebSphere MQ Client for Java'
PutDate : '20110922' PutTime : '13331348'
ApplOriginData : ' '
GroupId : X'000000000000000000000000000000000000000000000000'
MsgSeqNumber : '1'
Offset : '0'
MsgFlags : '0'
OriginalLength : '-1'
**** Message ****
length - 1630 bytes
Response:
MQGET of message number 1
****Message descriptor****
StrucId : 'MD ' Version : 2
Report : 0 MsgType : 2
Expiry : 8639606 Feedback : 0
Encoding : 546 CodedCharSetId : 819
Format : 'MQSTR '
Priority : 0 Persistence : 1
MsgId : X'C3E2D840E7C3D4E34040404040404040C869813289220C92'
CorrelId : X'414D5120584E475457303145202020204DFB44A025225A03'
BackoutCount : 0
ReplyToQ : 'QA.XN.0000/HMV_VRS_REP.T '
ReplyToQMgr : 'GTW01T '
** Identity Context
UserIdentifier : 'xi50 '
ApplIdentityData : ' '
** Origin Context
PutApplType : '6'
PutApplName : 'WebSphere Datapower MQClient'
PutDate : '20110922' PutTime : '13371510'
ApplOriginData : ' '
GroupId : X'000000000000000000000000000000000000000000000000'
MsgSeqNumber : '1'
Offset : '0'
MsgFlags : '0'
OriginalLength : '-1'
**** Message ****
length - 963 bytes
This is with useConduitSelector and conduitSelectorPrefix in use. You can
see that CXF sets a correlation ID on the request, and the server returns
the message ID as the correlation ID. CXF fails to correlate that
message.
Jens
--
View this message in context:
http://cxf.547215.n5.nabble.com/JMS-Message-Correlation-in-CXF-2-3-tp4830121p4873078.html
Sent from the cxf-user mailing list archive at Nabble.com.
--
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
