Re: Support for using JMS MessageID as CorrelationID

2010-04-23 Thread Willem Jiang
Hi Seumas, I'm sorry to reply your mail so late, please check out my comments in the mail. Seumas Soltysik wrote: There are a couple of elements in the JMSConduit code on the trunk that are troublesome. First of all there is the use of the outstandingAsync data member. Effectively it keeps t

RE: Support for using JMS MessageID as CorrelationID

2010-04-16 Thread Seumas Soltysik
l Kulp; dev@cxf.apache.org Subject: RE: Support for using JMS MessageID as CorrelationID Dan, Understood. However, in the case when the MessageID is used as the CorrelationID you must have a listener per invocation to support the asynch case as you must select specifically for the exact MessageI

RE: Support for using JMS MessageID as CorrelationID

2010-04-16 Thread Seumas Soltysik
@cxf.apache.org Cc: Seumas Soltysik Subject: Re: Support for using JMS MessageID as CorrelationID Seumas, The point is that in an async case, we do NOT want threads being consumed for a receive if at all possible. At Progress, we had a particular customer that would have several THOUSAND outstanding

Re: Support for using JMS MessageID as CorrelationID

2010-04-16 Thread Daniel Kulp
> From: Willem Jiang [willem.ji...@gmail.com] > Sent: Friday, April 16, 2010 9:48 AM > To: dev@cxf.apache.org > Subject: Re: Support for using JMS MessageID as CorrelationID > > If the JMSListener is the Spring DefaultMessageListenerContainer, I > doubt you can

RE: Support for using JMS MessageID as CorrelationID

2010-04-16 Thread Seumas Soltysik
48 AM To: dev@cxf.apache.org Subject: Re: Support for using JMS MessageID as CorrelationID If the JMSListener is the Spring DefaultMessageListenerContainer, I doubt you can change the listener's message selector at the runtime. So I suggest to create a receive task with jms message selector

Re: Support for using JMS MessageID as CorrelationID

2010-04-16 Thread Willem Jiang
llem Jiang [willem.ji...@gmail.com] Sent: Thursday, April 15, 2010 10:24 PM To: dev@cxf.apache.org Subject: Re: Support for using JMS MessageID as CorrelationID Hi Seumas, Please see my comments in the mail. Seumas Soltysik wrote: I am trying to get support for using the JMS MessageID

RE: Support for using JMS MessageID as CorrelationID

2010-04-16 Thread Seumas Soltysik
em.ji...@gmail.com] Sent: Thursday, April 15, 2010 10:24 PM To: dev@cxf.apache.org Subject: Re: Support for using JMS MessageID as CorrelationID Hi Seumas, Please see my comments in the mail. Seumas Soltysik wrote: > I am trying to get support for using the JMS MessageID as the JMS > Corre

RE: Support for using JMS MessageID as CorrelationID

2010-04-16 Thread Seumas Soltysik
: dev@cxf.apache.org Subject: Re: Support for using JMS MessageID as CorrelationID Hi Seumas, Please see my comments in the mail. Seumas Soltysik wrote: > I am trying to get support for using the JMS MessageID as the JMS > CorrelationID as specified in https://issues.apache.org/jira/brow

Re: Support for using JMS MessageID as CorrelationID

2010-04-16 Thread Christian Schneider
Hi Seumas, I also would prefer a property to activate the message id pattern. So I think we should use the same property on trunk and the branches. I really donĀ“t like how the code on the trunk developed recently. On 2.2.x it was quite understandable while I must say I am not sure I completely

Re: Support for using JMS MessageID as CorrelationID

2010-04-15 Thread Willem Jiang
Hi Seumas, Please see my comments in the mail. Seumas Soltysik wrote: I am trying to get support for using the JMS MessageID as the JMS CorrelationID as specified in https://issues.apache.org/jira/browse/CXF-2760 . After putting some work/thought into this issue, I became aware that this featu

Support for using JMS MessageID as CorrelationID

2010-04-15 Thread Seumas Soltysik
I am trying to get support for using the JMS MessageID as the JMS CorrelationID as specified in https://issues.apache.org/jira/browse/CXF-2760 . After putting some work/thought into this issue, I became aware that this feature is available on the trunk but was not back-merged to the 2.1.x and 2.