camel-dev mailing list archives

2011/1/20 Łukasz Dywicki <luke@code-house.org>:
> IMO it should be not supported. Queue nature is one way and publishing
> requests and responses to same queue is horrible idea. If you going to
> support all scenarios your components will start containing a lot of logic
> not strictly related to integration but very custom scenarios which may be
> called anti-patterns.
>
> Have you seen two way queue is shop? :)
>
Yeah I couldn't find any good use-case reason myself. So I think we
should create a ticket and then fix this issue.
Should we do a quick fix before the 2.6 release or would it be better
to wait for 2.7? The latter allows us to have more time testing and
avoid introducing any unforeseen side effect.
> Best regards,
> Lukasz
>
>
> -----Original Message-----
> From: Willem Jiang [mailto:willem.jiang@gmail.com]
> Sent: Thursday, January 20, 2011 8:31 AM
> To: dev@camel.apache.org
> Subject: Re: [DISCUSS] - JMSReplyTo to yourself
>
> Yes, CXF JMS transport support to use same queue for request and
> response, and it use the selector to check the correlationID.
>
> I think the failed test is caused by the message exchange pattern is
> InOut, and if the test box is slower to shutdown the camel context, you
> will get as many as possible message which is set as the response
> message to bar queue.
>
> BTW, current JMS consumer set the message exchange pattern by looking up
> the replyDestination header from the message, maybe we need to think
> about filter the replyTo header when put the reply message back to the
> queue to avoid this kind of error.
>
>
> Willem
>
> On 1/20/11 3:02 PM, Christian Schneider wrote:
>> Hi Claus,
>>
>> I also have not seen people using the same queue for replies. Although
>> it would be possible o do so using message selectors. So if we want to
>> block this we should allow people to override. Something like
>> ?allowReplyToSameDestination=true
>>
>> Christian
>>
>>
>> Am 20.01.2011 07:38, schrieb Claus Ibsen:
>>> Hi
>>>
>>> Suppose you have a Camel route
>>>
>>> from("activemq:queue:foo")
>>> .process(xxx)
>>>
>>> And a client sends a message to the foo queue with a JMSReplyTo header
>>> set with the queue:foo destination.
>>> The client has essentially told to send a reply back to the same queue
>>> as the message was consumed.
>>>
>>> Currently Camel will happily comply and send a reply message to the
>>> foo queue. Now what could happen is the message will keep doing this.
>>>
>>> Is there any use-cases in the real life where you want to send a reply
>>> message back to the same message queue?
>>> If not we can implement logic to detect this and avoid doing that.
>>> Camel can log a WARN when it has detect this so
>>> end users can notice in the logs if they have such a case.
>>>
>>> We can introduce an option so people can turn this odd behavior on and
>>> allow to send back replies to same queue.
>>>
>>>
>>> The current remedy is to enable this option as follows:
>>>
>>> from("activemq:queue:foo?disableReplyTo=true")
>>> .process(xxx)
>>>
>>> But that's general so if there was a JMSReplyTo header with the
>>> queue:bar then it would be ignored as well.
>>> However sending to a bar queue may be a valid use-case.
>>>
>>>
>>>
>>>
>>
>
>
> --
> Willem
> ----------------------------------
> FuseSource
> Web: http://www.fusesource.com
> Blog: http://willemjiang.blogspot.com (English)
> http://jnn.javaeye.com (Chinese)
> Twitter: willemjiang
>
>
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/