You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Jens <sm...@dzbank.de> on 2011/09/22 15:15:24 UTC
JMS Message Correlation in CXF 2.3+
In version 2.1 and 2.2 CXF had a property useMessageIDAsCorrelationID on the
JMSConfiguration to adjust how the client correlates JMS messages. The
property wsa introduced in CXF-2760, and in that issue Willem mentions that
in 2.3 (and later, I presume) CXF has a new way to achieve the same result.
What is that new way? I haven't been able to find anything similar, and the
old property is no longer available.
Thanks,
Jens
--
View this message in context: http://cxf.547215.n5.nabble.com/JMS-Message-Correlation-in-CXF-2-3-tp4830121p4830121.html
Sent from the cxf-user mailing list archive at Nabble.com.
Antwort: Re: JMS Message Correlation in CXF 2.3+
Posted by sm...@dzbank.de.
This is what worked with 2.2:
<bean id="jmsConfig"
class="org.apache.cxf.transport.jms.JMSConfiguration">
<property name="connectionFactory" ref="jmsConnectionFactory"/>
<property name="targetDestination"
value="queue:///out.queue?targetClient=1"/>
<property name="replyDestination" value="queue:///in.queue"/>
<property name="replyToDestination" value="queue://oqm/in.queue"/>
<property name="receiveTimeout" value="30000"/>
<property name="useConduitIdSelector" value="true"/>
<property name="conduitSelectorPrefix" value="ID:"/>
<property name="messageType" value="byte"/>
<property name="useMessageIDAsCorrelationID" value="true"/>
</bean>
Jens
Re: JMS Message Correlation in CXF 2.3+
Christian Schneider
An:
users
30.09.2011 14:41
Bitte Antwort an users
Can you post your config?
Christian
Am 30.09.2011 14:00, schrieb Jens:
> Hi Christian,
>
> thanks for your reply.
>
> I had a look at the code, too. I guess my problem is that I need to a
> conduitSelectorPrefix with WebSphere MQ ("ID:"), otherwise CXF cannot
> correlate anything at all.
>
> My attempts to hack the conduit to support this have unfortunately not
been
> successful so far.
>
> I'm running 2.3.2 at the moment but I think the code's pretty much
unchanged
> in trunk.
>
> Jens
>
>
> Christian Schneider wrote:
>> sorry for the delay. I just created a testcase for this as I found none
>> that was testing this case.
>>
>> See below for the algorithm to determine the correlation id to send out.
>> So if you do not set a conduitSelectorPrefix and use a sync call and do
>> not set useConduitIdSelector then it should work. In this case CXF will
>> correlate using the message id.
>>
>> That is at least the trunk setting. What version of CXF are you using?
>>
>> Christian
>>
> --
> View this message in context:
http://cxf.547215.n5.nabble.com/JMS-Message-Correlation-in-CXF-2-3-tp4830121p4856808.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
Re: JMS Message Correlation in CXF 2.3+
Posted by Jens <sm...@dzbank.de>.
Willem.Jiang wrote
>
> If you are using camel-cxf, you can using the option "synchronous=true" in
> your camel-cxf endpoint to let it call the service in synchronized mode.
>
Hi Willem,
I'm not normally using camel-cxf in these scenarios, although I guess I
could add an intermediate endpoint as a workaround. That's basically how
we've solved this use case anyway, but using a custom component (that I'd
like to get rid of) instead of Camel.
Jens
--
View this message in context: http://cxf.547215.n5.nabble.com/JMS-Message-Correlation-in-CXF-2-3-tp4830121p5606116.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: JMS Message Correlation in CXF 2.3+
Posted by "Willem.Jiang" <wi...@gmail.com>.
If you are using camel-cxf, you can using the option "synchronous=true" in
your camel-cxf endpoint to let it call the service in synchronized mode.
Willem
--
View this message in context: http://cxf.547215.n5.nabble.com/JMS-Message-Correlation-in-CXF-2-3-tp4830121p5605948.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: JMS Message Correlation in CXF 2.3+
Posted by Christian Schneider <ch...@die-schneider.net>.
Hi Jens,
I think this can not be done easily in the async case as we are using
the blocking method jmsTemplate.receiveSelected(replyToDestination,
messageSelector)
which would not be suitable for the async case. We could of course start
a thread to listen for the answer. I will check if this can be done.
Christian
Am 07.10.2011 15:23, schrieb Jens:
> Hi Christian,
>
> sorry for the slow reponse, I got sidetracked a little.
>
> Anyway, here's a header dump of a request message without the conduit
> parameters:
>
> MQGET of message number 1
> ****Message descriptor****
>
> StrucId : 'MD ' Version : 2
> Report : 0 MsgType : 1
> Expiry : -1 Feedback : 0
> Encoding : 273 CodedCharSetId : 1208
> Format : ' '
> Priority : 4 Persistence : 1
> MsgId : X'414D5120584E475457303154202020204E82B77221057307'
> CorrelId : X'633566363263653466346265343031373862343435306663'
> BackoutCount : 0
> ReplyToQ : 'QA.XN.0000/HMV_VRS_REP '
> ReplyToQMgr : 'GTW01T '
>
> As you can see, it has a correlationId set regardless. After a bit of
> debugging it looks like what I thought was a synchronous exchange in fact is
> not (I'm using CXF inside a Camel route). Since all of the msgId vs.
> correlationId logic in CXF apparently only applies to the synchronous case I
> guess that explains why it doesn't work. Is there a way to enable it for
> asynchronous exchanges as well?
>
> Regards,
> Jens
>
>
> Christian Schneider wrote:
>> 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
>>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/JMS-Message-Correlation-in-CXF-2-3-tp4830121p4880031.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
Re: JMS Message Correlation in CXF 2.3+
Posted by Jens <sm...@dzbank.de>.
Hi Christian,
sorry for the slow reponse, I got sidetracked a little.
Anyway, here's a header dump of a request message without the conduit
parameters:
MQGET of message number 1
****Message descriptor****
StrucId : 'MD ' Version : 2
Report : 0 MsgType : 1
Expiry : -1 Feedback : 0
Encoding : 273 CodedCharSetId : 1208
Format : ' '
Priority : 4 Persistence : 1
MsgId : X'414D5120584E475457303154202020204E82B77221057307'
CorrelId : X'633566363263653466346265343031373862343435306663'
BackoutCount : 0
ReplyToQ : 'QA.XN.0000/HMV_VRS_REP '
ReplyToQMgr : 'GTW01T '
As you can see, it has a correlationId set regardless. After a bit of
debugging it looks like what I thought was a synchronous exchange in fact is
not (I'm using CXF inside a Camel route). Since all of the msgId vs.
correlationId logic in CXF apparently only applies to the synchronous case I
guess that explains why it doesn't work. Is there a way to enable it for
asynchronous exchanges as well?
Regards,
Jens
Christian Schneider wrote:
>
> 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
>
--
View this message in context: http://cxf.547215.n5.nabble.com/JMS-Message-Correlation-in-CXF-2-3-tp4830121p4880031.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: JMS Message Correlation in CXF 2.3+
Posted by Christian Schneider <ch...@die-schneider.net>.
This is exactly what CXF is doing if you do not set the conduitId
properties.
This is from the JmsConduit. I removed some lines in between:
---
jmsTemplate.send(jmsConfig.getTargetDestination(), messageCreator);
correlationId = messageCreator.getMessageID();
final String messageSelector = "JMSCorrelationID = '" + correlationId + "'";
javax.jms.Message replyMessage = jmsTemplate.receiveSelected(replyToDestination, messageSelector);
---
Christian
Am 07.10.2011 10:55, schrieb David Karlsen:
> This is how I have implemented req/res on top of WMQ - but should really
> work on any JMS impl.:
> doSend( producer, requestMessage );
> correlationId = requestMessage.getJMSMessageID();
> String selector = "JMSCorrelationID = '" + correlationId + "'"; //hard to
> read on mail - but it quotes the ' char
> Object result = receiveSelectedAndConvert( replyToDestination, selector );
>
> 2011/10/7 Christian Schneider<ch...@die-schneider.net>
>
--
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: JMS Message Correlation in CXF 2.3+
Posted by David Karlsen <da...@gmail.com>.
This is how I have implemented req/res on top of WMQ - but should really
work on any JMS impl.:
doSend( producer, requestMessage );
correlationId = requestMessage.getJMSMessageID();
String selector = "JMSCorrelationID = '" + correlationId + "'"; //hard to
read on mail - but it quotes the ' char
Object result = receiveSelectedAndConvert( replyToDestination, selector );
2011/10/7 Christian Schneider <ch...@die-schneider.net>
> 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'**414D5120584E475457303145202020**204DFB44A025225A03'
>>>> CorrelId : X'**3D9F3E81D1AB424BB0BB43D47D231A**AF0000000000000002'
>>>> 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'**000000000000000000000000000000**000000000000000000'
>>>> 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'**C3E2D840E7C3D4E340404040404040**40C869813289220C92'
>>>> CorrelId : X'**414D5120584E475457303145202020**204DFB44A025225A03'
>>>> 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'**000000000000000000000000000000**000000000000000000'
>>>> 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<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
>
>
--
--
David J. M. Karlsen - http://www.linkedin.com/in/davidkarlsen
Re: JMS Message Correlation in CXF 2.3+
Posted by Christian Schneider <ch...@die-schneider.net>.
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
Re: JMS Message Correlation in CXF 2.3+
Posted by Jens <sm...@dzbank.de>.
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.
Re: JMS Message Correlation in CXF 2.3+
Posted by Christian Schneider <ch...@die-schneider.net>.
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
Re: JMS Message Correlation in CXF 2.3+
Posted by Jens <sm...@dzbank.de>.
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.
Re: JMS Message Correlation in CXF 2.3+
Posted by Christian Schneider <ch...@die-schneider.net>.
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
Am 04.10.2011 12:21, schrieb Jens:
> Hi Christian,
>
> unfortunately, no. I have never been able to correlate anything with
> WebSphere MQ without using the conduitIdSelectorPrefix. (That's what the
> option is for, I presume?)
>
> Regards,
> Jens
>
>
>
--
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: JMS Message Correlation in CXF 2.3+
Posted by Jens <sm...@dzbank.de>.
Hi Christian,
unfortunately, no. I have never been able to correlate anything with
WebSphere MQ without using the conduitIdSelectorPrefix. (That's what the
option is for, I presume?)
Regards,
Jens
Christian Schneider wrote:
>
> Hi Jens,
>
> thanks for the explanation. Now I understand your use case. You need the
> separate replyToDestination to tell the server to send to its local queue.
> While I think this should be rather hidden from the client I can imagine
> that it is necessary.
>
> So I think you should be able to just leave out the useConduitIdSelector
> and conduitIdSelectorPrefix. If you do not set these then CXF will
> correlate on the message id and set up a selector that matches the
> message id it sends out.
>
> So the below config should work.
>
> [bean id="jmsConfig"
> class="org.apache.cxf.transport.jms.JMSConfiguration"]
> [property name="connectionFactory" ref="jmsConnectionFactory"/]
> [property name="targetDestination"
> value="queue:///out.queue?targetClient=1"/]
> [property name="replyDestination" value="queue:///in.queue"/]
> [property name="replyToDestination"
> value="queue://oqm/in.queue"/]
> [property name="receiveTimeout" value="30000"/]
> [property name="messageType" value="byte"/]
> [/bean]
>
>
> Christian
>
>
>
> Am 04.10.2011 09:47, schrieb Jens:
>> Hi Christian,
>>
>> they must be set to different names because the server is listening on a
>> different queue at a different queue manager, and it doesn't know the
>> local
>> queue manager my application is talking to. My application sends its
>> messages to a local queue that automatically forwards to the other queue
>> manager, and the server sends its messages to a local queue on the remote
>> queue manager that automatically forwards to my local response queue.
>>
>> The configuration snippet is exactly what I have in my working setup with
>> CXF 2.2, so I can assure you that it can and does work. The only problem
>> is
>> that CXF 2.3/4 no longer supports the useMessageIDAsCorrelationID option
>> that 2.2 had.
>>
>> Regards,
>> Jens
>>
>>
>> Christian Schneider wrote:
>>> Hi Jens,
>>>
>>> why do you set replyDestination and replyToDestination to different
>>> names? I don´t think that this can work.
>>>
>>> The JMSConduit will always specify the replyDestination in the message
>>> it sends out. So the server should always send the reply there.
>>> When receiving the JMSConduit will use the replyToDestination if it is
>>> set. So it will probably never receive anything.
>>>
>>> Christian
>>>
>>>
>>> Am 30.09.2011 15:50, schrieb Jens:
>>>> Hi Christian,
>>>>
>>>> that won't work, primarily because I'm not allowed to use temporary
>>>> queues
>>>> (company policy) and the server is listening on a remote queue manager,
>>>> so
>>>> if I leave out replyToDestination it won't know where to send the
>>>> reply.
>>>>
>>>> Jens
>>>>
>>>>
>>>> Christian Schneider wrote:
>>>>> Hi Jens,
>>>>>
>>>>> why don´t you simply leave out replyDestination, replyToDestination,
>>>>> useConduitIdSelector, conduitIdSelectPrefix.
>>>>>
>>>>> Then cxf will use a temp queue for replies and the correlation should
>>>>> still work. Can you try this with the newest CXF?
>>>>>
>>>>> Christian
>>>>>
>>>>> Am 30.09.2011 15:25, schrieb Jens:
>>>>>> This is what worked with 2.2 (angle brackets replaced to get through
>>>>>> Nabble):
>>>>>>
>>>>>> [bean id="jmsConfig"
>>>>>> class="org.apache.cxf.transport.jms.JMSConfiguration"]
>>>>>> [property name="connectionFactory"
>>>>>> ref="jmsConnectionFactory"/]
>>>>>> [property name="targetDestination"
>>>>>> value="queue:///out.queue?targetClient=1"/]
>>>>>> [property name="replyDestination" value="queue:///in.queue"/]
>>>>>> [property name="replyToDestination"
>>>>>> value="queue://oqm/in.queue"/]
>>>>>> [property name="receiveTimeout" value="30000"/]
>>>>>> [property name="useConduitIdSelector" value="true"/]
>>>>>> [property name="conduitSelectorPrefix" value="ID:"/]
>>>>>> [property name="messageType" value="byte"/]
>>>>>> [property name="useMessageIDAsCorrelationID" value="true"/]
>>>>>> [/bean]
>>>>>>
>>>>>> Jens
>>>>>>
>>
>> --
>> View this message in context:
>> http://cxf.547215.n5.nabble.com/JMS-Message-Correlation-in-CXF-2-3-tp4830121p4867722.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
>
--
View this message in context: http://cxf.547215.n5.nabble.com/JMS-Message-Correlation-in-CXF-2-3-tp4830121p4868035.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: JMS Message Correlation in CXF 2.3+
Posted by Christian Schneider <ch...@die-schneider.net>.
Hi Jens,
thanks for the explanation. Now I understand your use case. You need the
separate replyToDestination to tell the server to send to its local queue.
While I think this should be rather hidden from the client I can imagine
that it is necessary.
So I think you should be able to just leave out the useConduitIdSelector
and conduitIdSelectorPrefix. If you do not set these then CXF will
correlate on the message id and set up a selector that matches the
message id it sends out.
So the below config should work.
[bean id="jmsConfig"
class="org.apache.cxf.transport.jms.JMSConfiguration"]
[property name="connectionFactory" ref="jmsConnectionFactory"/]
[property name="targetDestination"
value="queue:///out.queue?targetClient=1"/]
[property name="replyDestination" value="queue:///in.queue"/]
[property name="replyToDestination"
value="queue://oqm/in.queue"/]
[property name="receiveTimeout" value="30000"/]
[property name="messageType" value="byte"/]
[/bean]
Christian
Am 04.10.2011 09:47, schrieb Jens:
> Hi Christian,
>
> they must be set to different names because the server is listening on a
> different queue at a different queue manager, and it doesn't know the local
> queue manager my application is talking to. My application sends its
> messages to a local queue that automatically forwards to the other queue
> manager, and the server sends its messages to a local queue on the remote
> queue manager that automatically forwards to my local response queue.
>
> The configuration snippet is exactly what I have in my working setup with
> CXF 2.2, so I can assure you that it can and does work. The only problem is
> that CXF 2.3/4 no longer supports the useMessageIDAsCorrelationID option
> that 2.2 had.
>
> Regards,
> Jens
>
>
> Christian Schneider wrote:
>> Hi Jens,
>>
>> why do you set replyDestination and replyToDestination to different
>> names? I don´t think that this can work.
>>
>> The JMSConduit will always specify the replyDestination in the message
>> it sends out. So the server should always send the reply there.
>> When receiving the JMSConduit will use the replyToDestination if it is
>> set. So it will probably never receive anything.
>>
>> Christian
>>
>>
>> Am 30.09.2011 15:50, schrieb Jens:
>>> Hi Christian,
>>>
>>> that won't work, primarily because I'm not allowed to use temporary
>>> queues
>>> (company policy) and the server is listening on a remote queue manager,
>>> so
>>> if I leave out replyToDestination it won't know where to send the reply.
>>>
>>> Jens
>>>
>>>
>>> Christian Schneider wrote:
>>>> Hi Jens,
>>>>
>>>> why don´t you simply leave out replyDestination, replyToDestination,
>>>> useConduitIdSelector, conduitIdSelectPrefix.
>>>>
>>>> Then cxf will use a temp queue for replies and the correlation should
>>>> still work. Can you try this with the newest CXF?
>>>>
>>>> Christian
>>>>
>>>> Am 30.09.2011 15:25, schrieb Jens:
>>>>> This is what worked with 2.2 (angle brackets replaced to get through
>>>>> Nabble):
>>>>>
>>>>> [bean id="jmsConfig"
>>>>> class="org.apache.cxf.transport.jms.JMSConfiguration"]
>>>>> [property name="connectionFactory" ref="jmsConnectionFactory"/]
>>>>> [property name="targetDestination"
>>>>> value="queue:///out.queue?targetClient=1"/]
>>>>> [property name="replyDestination" value="queue:///in.queue"/]
>>>>> [property name="replyToDestination"
>>>>> value="queue://oqm/in.queue"/]
>>>>> [property name="receiveTimeout" value="30000"/]
>>>>> [property name="useConduitIdSelector" value="true"/]
>>>>> [property name="conduitSelectorPrefix" value="ID:"/]
>>>>> [property name="messageType" value="byte"/]
>>>>> [property name="useMessageIDAsCorrelationID" value="true"/]
>>>>> [/bean]
>>>>>
>>>>> Jens
>>>>>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/JMS-Message-Correlation-in-CXF-2-3-tp4830121p4867722.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
Re: JMS Message Correlation in CXF 2.3+
Posted by Jens <sm...@dzbank.de>.
Hi Christian,
they must be set to different names because the server is listening on a
different queue at a different queue manager, and it doesn't know the local
queue manager my application is talking to. My application sends its
messages to a local queue that automatically forwards to the other queue
manager, and the server sends its messages to a local queue on the remote
queue manager that automatically forwards to my local response queue.
The configuration snippet is exactly what I have in my working setup with
CXF 2.2, so I can assure you that it can and does work. The only problem is
that CXF 2.3/4 no longer supports the useMessageIDAsCorrelationID option
that 2.2 had.
Regards,
Jens
Christian Schneider wrote:
>
> Hi Jens,
>
> why do you set replyDestination and replyToDestination to different
> names? I don´t think that this can work.
>
> The JMSConduit will always specify the replyDestination in the message
> it sends out. So the server should always send the reply there.
> When receiving the JMSConduit will use the replyToDestination if it is
> set. So it will probably never receive anything.
>
> Christian
>
>
> Am 30.09.2011 15:50, schrieb Jens:
>> Hi Christian,
>>
>> that won't work, primarily because I'm not allowed to use temporary
>> queues
>> (company policy) and the server is listening on a remote queue manager,
>> so
>> if I leave out replyToDestination it won't know where to send the reply.
>>
>> Jens
>>
>>
>> Christian Schneider wrote:
>>> Hi Jens,
>>>
>>> why don´t you simply leave out replyDestination, replyToDestination,
>>> useConduitIdSelector, conduitIdSelectPrefix.
>>>
>>> Then cxf will use a temp queue for replies and the correlation should
>>> still work. Can you try this with the newest CXF?
>>>
>>> Christian
>>>
>>> Am 30.09.2011 15:25, schrieb Jens:
>>>> This is what worked with 2.2 (angle brackets replaced to get through
>>>> Nabble):
>>>>
>>>> [bean id="jmsConfig"
>>>> class="org.apache.cxf.transport.jms.JMSConfiguration"]
>>>> [property name="connectionFactory" ref="jmsConnectionFactory"/]
>>>> [property name="targetDestination"
>>>> value="queue:///out.queue?targetClient=1"/]
>>>> [property name="replyDestination" value="queue:///in.queue"/]
>>>> [property name="replyToDestination"
>>>> value="queue://oqm/in.queue"/]
>>>> [property name="receiveTimeout" value="30000"/]
>>>> [property name="useConduitIdSelector" value="true"/]
>>>> [property name="conduitSelectorPrefix" value="ID:"/]
>>>> [property name="messageType" value="byte"/]
>>>> [property name="useMessageIDAsCorrelationID" value="true"/]
>>>> [/bean]
>>>>
>>>> Jens
>>>>
>
--
View this message in context: http://cxf.547215.n5.nabble.com/JMS-Message-Correlation-in-CXF-2-3-tp4830121p4867722.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: JMS Message Correlation in CXF 2.3+
Posted by Christian Schneider <ch...@die-schneider.net>.
Hi Jens,
why do you set replyDestination and replyToDestination to different
names? I don´t think that this can work.
The JMSConduit will always specify the replyDestination in the message
it sends out. So the server should always send the reply there.
When receiving the JMSConduit will use the replyToDestination if it is
set. So it will probably never receive anything.
Christian
Am 30.09.2011 15:50, schrieb Jens:
> Hi Christian,
>
> that won't work, primarily because I'm not allowed to use temporary queues
> (company policy) and the server is listening on a remote queue manager, so
> if I leave out replyToDestination it won't know where to send the reply.
>
> Jens
>
>
> Christian Schneider wrote:
>> Hi Jens,
>>
>> why don´t you simply leave out replyDestination, replyToDestination,
>> useConduitIdSelector, conduitIdSelectPrefix.
>>
>> Then cxf will use a temp queue for replies and the correlation should
>> still work. Can you try this with the newest CXF?
>>
>> Christian
>>
>> Am 30.09.2011 15:25, schrieb Jens:
>>> This is what worked with 2.2 (angle brackets replaced to get through
>>> Nabble):
>>>
>>> [bean id="jmsConfig"
>>> class="org.apache.cxf.transport.jms.JMSConfiguration"]
>>> [property name="connectionFactory" ref="jmsConnectionFactory"/]
>>> [property name="targetDestination"
>>> value="queue:///out.queue?targetClient=1"/]
>>> [property name="replyDestination" value="queue:///in.queue"/]
>>> [property name="replyToDestination" value="queue://oqm/in.queue"/]
>>> [property name="receiveTimeout" value="30000"/]
>>> [property name="useConduitIdSelector" value="true"/]
>>> [property name="conduitSelectorPrefix" value="ID:"/]
>>> [property name="messageType" value="byte"/]
>>> [property name="useMessageIDAsCorrelationID" value="true"/]
>>> [/bean]
>>>
>>> Jens
>>>
--
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: JMS Message Correlation in CXF 2.3+
Posted by Jens <sm...@dzbank.de>.
Hi Christian,
that won't work, primarily because I'm not allowed to use temporary queues
(company policy) and the server is listening on a remote queue manager, so
if I leave out replyToDestination it won't know where to send the reply.
Jens
Christian Schneider wrote:
>
> Hi Jens,
>
> why don´t you simply leave out replyDestination, replyToDestination,
> useConduitIdSelector, conduitIdSelectPrefix.
>
> Then cxf will use a temp queue for replies and the correlation should
> still work. Can you try this with the newest CXF?
>
> Christian
>
> Am 30.09.2011 15:25, schrieb Jens:
>> This is what worked with 2.2 (angle brackets replaced to get through
>> Nabble):
>>
>> [bean id="jmsConfig"
>> class="org.apache.cxf.transport.jms.JMSConfiguration"]
>> [property name="connectionFactory" ref="jmsConnectionFactory"/]
>> [property name="targetDestination"
>> value="queue:///out.queue?targetClient=1"/]
>> [property name="replyDestination" value="queue:///in.queue"/]
>> [property name="replyToDestination" value="queue://oqm/in.queue"/]
>> [property name="receiveTimeout" value="30000"/]
>> [property name="useConduitIdSelector" value="true"/]
>> [property name="conduitSelectorPrefix" value="ID:"/]
>> [property name="messageType" value="byte"/]
>> [property name="useMessageIDAsCorrelationID" value="true"/]
>> [/bean]
>>
>> Jens
>>
>>
>> Christian Schneider wrote:
>>> Can you post your config?
>>>
>>> Christian
>>>
>>>
>>> Am 30.09.2011 14:00, schrieb Jens:
>>>> Hi Christian,
>>>>
>>>> thanks for your reply.
>>>>
>>>> I had a look at the code, too. I guess my problem is that I need to a
>>>> conduitSelectorPrefix with WebSphere MQ ("ID:"), otherwise CXF cannot
>>>> correlate anything at all.
>>>>
>>>> My attempts to hack the conduit to support this have unfortunately not
>>>> been
>>>> successful so far.
>>>>
>>>> I'm running 2.3.2 at the moment but I think the code's pretty much
>>>> unchanged
>>>> in trunk.
>>>>
>>>> Jens
>>>>
>>>>
>>>> Christian Schneider wrote:
>>>>> sorry for the delay. I just created a testcase for this as I found
>>>>> none
>>>>> that was testing this case.
>>>>>
>>>>> See below for the algorithm to determine the correlation id to send
>>>>> out.
>>>>> So if you do not set a conduitSelectorPrefix and use a sync call and
>>>>> do
>>>>> not set useConduitIdSelector then it should work. In this case CXF
>>>>> will
>>>>> correlate using the message id.
>>>>>
>>>>> That is at least the trunk setting. What version of CXF are you using?
>>>>>
>>>>> Christian
>>>>>
>>>> --
>>>> View this message in context:
>>>> http://cxf.547215.n5.nabble.com/JMS-Message-Correlation-in-CXF-2-3-tp4830121p4856808.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
>>>
>>
>> --
>> View this message in context:
>> http://cxf.547215.n5.nabble.com/JMS-Message-Correlation-in-CXF-2-3-tp4830121p4857082.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
>
--
View this message in context: http://cxf.547215.n5.nabble.com/JMS-Message-Correlation-in-CXF-2-3-tp4830121p4857180.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: JMS Message Correlation in CXF 2.3+
Posted by Christian Schneider <ch...@die-schneider.net>.
Hi Jens,
why don´t you simply leave out replyDestination, replyToDestination,
useConduitIdSelector, conduitIdSelectPrefix.
Then cxf will use a temp queue for replies and the correlation should
still work. Can you try this with the newest CXF?
Christian
Am 30.09.2011 15:25, schrieb Jens:
> This is what worked with 2.2 (angle brackets replaced to get through Nabble):
>
> [bean id="jmsConfig"
> class="org.apache.cxf.transport.jms.JMSConfiguration"]
> [property name="connectionFactory" ref="jmsConnectionFactory"/]
> [property name="targetDestination"
> value="queue:///out.queue?targetClient=1"/]
> [property name="replyDestination" value="queue:///in.queue"/]
> [property name="replyToDestination" value="queue://oqm/in.queue"/]
> [property name="receiveTimeout" value="30000"/]
> [property name="useConduitIdSelector" value="true"/]
> [property name="conduitSelectorPrefix" value="ID:"/]
> [property name="messageType" value="byte"/]
> [property name="useMessageIDAsCorrelationID" value="true"/]
> [/bean]
>
> Jens
>
>
> Christian Schneider wrote:
>> Can you post your config?
>>
>> Christian
>>
>>
>> Am 30.09.2011 14:00, schrieb Jens:
>>> Hi Christian,
>>>
>>> thanks for your reply.
>>>
>>> I had a look at the code, too. I guess my problem is that I need to a
>>> conduitSelectorPrefix with WebSphere MQ ("ID:"), otherwise CXF cannot
>>> correlate anything at all.
>>>
>>> My attempts to hack the conduit to support this have unfortunately not
>>> been
>>> successful so far.
>>>
>>> I'm running 2.3.2 at the moment but I think the code's pretty much
>>> unchanged
>>> in trunk.
>>>
>>> Jens
>>>
>>>
>>> Christian Schneider wrote:
>>>> sorry for the delay. I just created a testcase for this as I found none
>>>> that was testing this case.
>>>>
>>>> See below for the algorithm to determine the correlation id to send out.
>>>> So if you do not set a conduitSelectorPrefix and use a sync call and do
>>>> not set useConduitIdSelector then it should work. In this case CXF will
>>>> correlate using the message id.
>>>>
>>>> That is at least the trunk setting. What version of CXF are you using?
>>>>
>>>> Christian
>>>>
>>> --
>>> View this message in context:
>>> http://cxf.547215.n5.nabble.com/JMS-Message-Correlation-in-CXF-2-3-tp4830121p4856808.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
>>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/JMS-Message-Correlation-in-CXF-2-3-tp4830121p4857082.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
Re: JMS Message Correlation in CXF 2.3+
Posted by Jens <sm...@dzbank.de>.
This is what worked with 2.2 (angle brackets replaced to get through Nabble):
[bean id="jmsConfig"
class="org.apache.cxf.transport.jms.JMSConfiguration"]
[property name="connectionFactory" ref="jmsConnectionFactory"/]
[property name="targetDestination"
value="queue:///out.queue?targetClient=1"/]
[property name="replyDestination" value="queue:///in.queue"/]
[property name="replyToDestination" value="queue://oqm/in.queue"/]
[property name="receiveTimeout" value="30000"/]
[property name="useConduitIdSelector" value="true"/]
[property name="conduitSelectorPrefix" value="ID:"/]
[property name="messageType" value="byte"/]
[property name="useMessageIDAsCorrelationID" value="true"/]
[/bean]
Jens
Christian Schneider wrote:
>
> Can you post your config?
>
> Christian
>
>
> Am 30.09.2011 14:00, schrieb Jens:
>> Hi Christian,
>>
>> thanks for your reply.
>>
>> I had a look at the code, too. I guess my problem is that I need to a
>> conduitSelectorPrefix with WebSphere MQ ("ID:"), otherwise CXF cannot
>> correlate anything at all.
>>
>> My attempts to hack the conduit to support this have unfortunately not
>> been
>> successful so far.
>>
>> I'm running 2.3.2 at the moment but I think the code's pretty much
>> unchanged
>> in trunk.
>>
>> Jens
>>
>>
>> Christian Schneider wrote:
>>> sorry for the delay. I just created a testcase for this as I found none
>>> that was testing this case.
>>>
>>> See below for the algorithm to determine the correlation id to send out.
>>> So if you do not set a conduitSelectorPrefix and use a sync call and do
>>> not set useConduitIdSelector then it should work. In this case CXF will
>>> correlate using the message id.
>>>
>>> That is at least the trunk setting. What version of CXF are you using?
>>>
>>> Christian
>>>
>> --
>> View this message in context:
>> http://cxf.547215.n5.nabble.com/JMS-Message-Correlation-in-CXF-2-3-tp4830121p4856808.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
>
--
View this message in context: http://cxf.547215.n5.nabble.com/JMS-Message-Correlation-in-CXF-2-3-tp4830121p4857082.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: JMS Message Correlation in CXF 2.3+
Posted by Christian Schneider <ch...@die-schneider.net>.
Can you post your config?
Christian
Am 30.09.2011 14:00, schrieb Jens:
> Hi Christian,
>
> thanks for your reply.
>
> I had a look at the code, too. I guess my problem is that I need to a
> conduitSelectorPrefix with WebSphere MQ ("ID:"), otherwise CXF cannot
> correlate anything at all.
>
> My attempts to hack the conduit to support this have unfortunately not been
> successful so far.
>
> I'm running 2.3.2 at the moment but I think the code's pretty much unchanged
> in trunk.
>
> Jens
>
>
> Christian Schneider wrote:
>> sorry for the delay. I just created a testcase for this as I found none
>> that was testing this case.
>>
>> See below for the algorithm to determine the correlation id to send out.
>> So if you do not set a conduitSelectorPrefix and use a sync call and do
>> not set useConduitIdSelector then it should work. In this case CXF will
>> correlate using the message id.
>>
>> That is at least the trunk setting. What version of CXF are you using?
>>
>> Christian
>>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/JMS-Message-Correlation-in-CXF-2-3-tp4830121p4856808.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
Re: JMS Message Correlation in CXF 2.3+
Posted by Jens <sm...@dzbank.de>.
Hi Christian,
thanks for your reply.
I had a look at the code, too. I guess my problem is that I need to a
conduitSelectorPrefix with WebSphere MQ ("ID:"), otherwise CXF cannot
correlate anything at all.
My attempts to hack the conduit to support this have unfortunately not been
successful so far.
I'm running 2.3.2 at the moment but I think the code's pretty much unchanged
in trunk.
Jens
Christian Schneider wrote:
>
> sorry for the delay. I just created a testcase for this as I found none
> that was testing this case.
>
> See below for the algorithm to determine the correlation id to send out.
> So if you do not set a conduitSelectorPrefix and use a sync call and do
> not set useConduitIdSelector then it should work. In this case CXF will
> correlate using the message id.
>
> That is at least the trunk setting. What version of CXF are you using?
>
> Christian
>
--
View this message in context: http://cxf.547215.n5.nabble.com/JMS-Message-Correlation-in-CXF-2-3-tp4830121p4856808.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: JMS Message Correlation in CXF 2.3+
Posted by Christian Schneider <ch...@die-schneider.net>.
Hi jens,
sorry for the delay. I just created a testcase for this as I found none
that was testing this case.
See below for the algorithm to determine the correlation id to send out.
So if you do not set a conduitSelectorPrefix and use a sync call and do
not set useConduitIdSelector then it should work. In this case CXF will
correlate using the message id.
That is at least the trunk setting. What version of CXF are you using?
Christian
---
The method in JMSConduit that determines the correlation id looks like
this now:
private String createCorrelationId(final Exchange exchange, String
userCID) {
String correlationId = null;
if (!exchange.isOneWay()) {
if (userCID != null) {
correlationId = userCID;
} else if (!jmsConfig.isSetConduitSelectorPrefix()
&& (exchange.isSynchronous() || exchange.isOneWay())
&& (!jmsConfig.isSetUseConduitIdSelector()
|| !jmsConfig.isUseConduitIdSelector())) {
// in this case the correlation id will be set to
// the message id later
correlationId = null;
} else {
String prefix = (jmsConfig.isUseConduitIdSelector())
? jmsConfig.getConduitSelectorPrefix() + conduitId
: jmsConfig.getConduitSelectorPrefix();
correlationId = JMSUtils.createCorrelationId(prefix,
messageCount.incrementAndGet());
}
}
return correlationId;
}
Am 27.09.2011 12:13, schrieb Jens:
> Hi,
>
> am I assuming correctly that the silence on this topic means it's not
> currently possible to do this?
>
> Seeing as the functionality was not ported to 2.3 in CXF-2760, does filing a
> new issue on this make sense?
>
> If I interpret the current code correctly, CXF uses the same semi-automatic
> approach that the underlying Spring JMS classes implement: If the user
> passes a correlationId use that for correlation, otherwise use the
> messageId. That sounds like it should work in many cases. However, I'm using
> WebSphereMQ which requires using a conduitSelectorPrefix. Unfortunatey, when
> a conduitSelectorPrefix is given CXF constructs a correlationId itself,
> thereby preempting the attempt to correlate on the messageId instead.
>
> Thanks,
> Jens
>
>
> Jens wrote:
>> Let me try to phrase the question differently. It looks like the CXF JMS
>> transport by default correlates the correlationId, ie. the client sets a
>> correlationId on the request that it expects to be returned as the
>> correlationId of the response.
>>
>> In my case I have a server that returns the messageId of the request as
>> the correlationId of the response. CXF obviously fails to correlate those
>> messages and eventually times out waiting for the message even though it
>> is sitting in the queue. In CXF prior to 2.3 the
>> useMessageIDAsCorrelationID property could be used to fix that issue. How
>> can I tell current CXF versions to change its correlation strategy?
>>
>>
>> Jens wrote:
>>> In version 2.1 and 2.2 CXF had a property useMessageIDAsCorrelationID on
>>> the JMSConfiguration to adjust how the client correlates JMS messages.
>>> The property was introduced in CXF-2760, and in that issue Willem
>>> mentions that in 2.3 (and later, I presume) CXF has a new way to achieve
>>> the same result. What is that new way? I haven't been able to find
>>> anything similar, and the old property is no longer available.
>>>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/JMS-Message-Correlation-in-CXF-2-3-tp4830121p4844782.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
Re: JMS Message Correlation in CXF 2.3+
Posted by Jens <sm...@dzbank.de>.
Hi,
am I assuming correctly that the silence on this topic means it's not
currently possible to do this?
Seeing as the functionality was not ported to 2.3 in CXF-2760, does filing a
new issue on this make sense?
If I interpret the current code correctly, CXF uses the same semi-automatic
approach that the underlying Spring JMS classes implement: If the user
passes a correlationId use that for correlation, otherwise use the
messageId. That sounds like it should work in many cases. However, I'm using
WebSphereMQ which requires using a conduitSelectorPrefix. Unfortunatey, when
a conduitSelectorPrefix is given CXF constructs a correlationId itself,
thereby preempting the attempt to correlate on the messageId instead.
Thanks,
Jens
Jens wrote:
>
> Let me try to phrase the question differently. It looks like the CXF JMS
> transport by default correlates the correlationId, ie. the client sets a
> correlationId on the request that it expects to be returned as the
> correlationId of the response.
>
> In my case I have a server that returns the messageId of the request as
> the correlationId of the response. CXF obviously fails to correlate those
> messages and eventually times out waiting for the message even though it
> is sitting in the queue. In CXF prior to 2.3 the
> useMessageIDAsCorrelationID property could be used to fix that issue. How
> can I tell current CXF versions to change its correlation strategy?
>
>
> Jens wrote:
>>
>> In version 2.1 and 2.2 CXF had a property useMessageIDAsCorrelationID on
>> the JMSConfiguration to adjust how the client correlates JMS messages.
>> The property was introduced in CXF-2760, and in that issue Willem
>> mentions that in 2.3 (and later, I presume) CXF has a new way to achieve
>> the same result. What is that new way? I haven't been able to find
>> anything similar, and the old property is no longer available.
>>
>
--
View this message in context: http://cxf.547215.n5.nabble.com/JMS-Message-Correlation-in-CXF-2-3-tp4830121p4844782.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: JMS Message Correlation in CXF 2.3+
Posted by Jens <sm...@dzbank.de>.
Let me try to phrase the question differently. It looks like the CXF JMS
transport by default correlates the correlationId, ie. the client sets a
correlationId on the request that it expects to be returned as the
correlationId of the response.
In my case I have a server that returns the messageId of the request as the
correlationId of the response. CXF obviously fails to correlate those
messages and eventually times out waiting for the message even though it is
sitting in the queue. In CXF prior to 2.3 the useMessageIDAsCorrelationID
property could be used to fix that issue. How can I tell current CXF
versions to change its correlation strategy?
Jens wrote:
>
> In version 2.1 and 2.2 CXF had a property useMessageIDAsCorrelationID on
> the JMSConfiguration to adjust how the client correlates JMS messages. The
> property was introduced in CXF-2760, and in that issue Willem mentions
> that in 2.3 (and later, I presume) CXF has a new way to achieve the same
> result. What is that new way? I haven't been able to find anything
> similar, and the old property is no longer available.
>
--
View this message in context: http://cxf.547215.n5.nabble.com/JMS-Message-Correlation-in-CXF-2-3-tp4830121p4840515.html
Sent from the cxf-user mailing list archive at Nabble.com.