I *think* I would leave it as is. You are right, This is a valid usecase *if*
selectors are used. The extra allowReplyToSameDestination configuration would
be required for this scenario. It gets trickier with dynamic recipients. This
makes configuration imho unnecessarily more complicated. This scenario could
easily be addressed by documentation. Or maybe not logging at WARN, but at
INFO, would help a bit.
We must assume users know what they're doing. From my experience, in the
majority of cases, that is the case.
Cheers,
Hadrian
On Jan 20, 2011, at 2:02 AM, 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.
>>
>>
>>
>>
>
> --
> ----
> http://www.liquid-reality.de
>
