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
Christian Schneider wrote:
The selector for the correlation id seems to be only used for
synchronous calls. Is that the case for your project or do you call the
client asynchronously? In the sync case I would expect the code to work.
Can you do some dumps of the messages going in and out of cxf and on the
queues?
It would be especially intersting what the message id, replyTo and
correlationId headers look like.
Thanks
Christian
--
View this message in context:
http://cxf.547215.n5.nabble.com/JMS-Message-Correlation-in-CXF-2-3-tp4830121p4872370.html
Sent from the cxf-user mailing list archive at Nabble.com.
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
