JMS Message Correlation in CXF 2.3+

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

JMS Message Correlation in CXF 2.3+

Jens
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
Reply | Threaded
Open this post in threaded view
|

Re: JMS Message Correlation in CXF 2.3+

Jens
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.
Reply | Threaded
Open this post in threaded view
|

Re: JMS Message Correlation in CXF 2.3+

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.
Reply | Threaded
Open this post in threaded view
|

Re: JMS Message Correlation in CXF 2.3+

cschneider
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

Reply | Threaded
Open this post in threaded view
|

Re: JMS Message Correlation in CXF 2.3+

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
Reply | Threaded
Open this post in threaded view
|

Re: JMS Message Correlation in CXF 2.3+

cschneider
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

Reply | Threaded
Open this post in threaded view
|

Antwort: Re: JMS Message Correlation in CXF 2.3+

Jens

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


Christian Schneider ---30.09.2011 14:41:22---Can you post your config? Christian



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


Reply | Threaded
Open this post in threaded view
|

Re: JMS Message Correlation in CXF 2.3+

Jens
In reply to this post by cschneider
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
Reply | Threaded
Open this post in threaded view
|

Re: JMS Message Correlation in CXF 2.3+

cschneider
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

Reply | Threaded
Open this post in threaded view
|

Re: JMS Message Correlation in CXF 2.3+

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 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
Reply | Threaded
Open this post in threaded view
|

Re: JMS Message Correlation in CXF 2.3+

cschneider
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

Reply | Threaded
Open this post in threaded view
|

Re: JMS Message Correlation in CXF 2.3+

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
>>>
Reply | Threaded
Open this post in threaded view
|

Re: JMS Message Correlation in CXF 2.3+

cschneider
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

Reply | Threaded
Open this post in threaded view
|

Re: JMS Message Correlation in CXF 2.3+

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 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
Reply | Threaded
Open this post in threaded view
|

Re: JMS Message Correlation in CXF 2.3+

cschneider
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

Reply | Threaded
Open this post in threaded view
|

Re: JMS Message Correlation in CXF 2.3+

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
Reply | Threaded
Open this post in threaded view
|

Re: JMS Message Correlation in CXF 2.3+

cschneider
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

Reply | Threaded
Open this post in threaded view
|

Re: JMS Message Correlation in CXF 2.3+

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
Reply | Threaded
Open this post in threaded view
|

Re: JMS Message Correlation in CXF 2.3+

cschneider
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

Reply | Threaded
Open this post in threaded view
|

Re: JMS Message Correlation in CXF 2.3+

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 <[hidden email]>

> 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
12