camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <claus.ib...@gmail.com>
Subject Re: set jms reply to in message header
Date Fri, 27 May 2011 07:53:00 GMT
On Fri, May 27, 2011 at 4:38 AM, Jim Newsham <jnewsham@referentia.com> wrote:
>
> Hi Willem,
>
> We do not want to use a temporary queue for replies, because it is scoped to
> the lifetime of the connection, and any data sent to that queue will be lost
> if the connection gets lost for some reason.
>
> We can't set the replyTo queue at route definition time because the reply
> queue name is not known until after communication is established.
>

You could figure out the reply to queue up front, and then have that
adjusted/set into the route.


> In fact, in our application we are only using a single JMS queue for all
> replies, which will be used for the duration of the application, so (for us)
> there is no memory/thread resource leak issue.  I can understand how this
> feature, if used/abused by others, may cause a resource problem.
>
> 1.  Is there some reason Camel must use a separate thread per reply queue,
> instead of using the JMS dispatch thread or a shared Camel dispatch thread?

The main reason for the current design is that its using a spring DMLC
for listening for the replies.

There are challenges. If using a named reply queue, you would have to
use persistent queues, as the reply may come back faster, than the
dispatcher thread can keep up and start consuming. Also what about
timeout? The dispatcher thread would have to have a built-in control
for triggering timeouts and whatnot.
Also the async routing engine allows for scalability, as the
dispatcher thread, can go about do something else. While the reply is
being waited for.


> 2.  Otherwise, could this "leak" be documented as a limitation?
>
> I think this feature can be useful, if it can be supported, since it
> provides more implementation flexibility/dynamism.  However if it cannot be
> supported, I think I should be able to work around it.
>

We are just a bit concerned to add more features and whatnot to
camel-jms as its already feature rich. Although many of the features
comes inherited from spring jms.

So in your use-case the reply to destination is computed based on
message information (eg dynamic). So end users have to be a bit
careful to not compute a zillion dynamic reply to destinations. You
say you compute only one, so you should be okay.

If we decide to keep this feature, we need to add a documentation
snippet that stand out, so ppl can notice its caveats.

Likewise this feature may cause a bit "confusing" about the existing
JMSReplyTo header. So we need to more careful document the differences
and details about those 2.


> Thanks,
> Jim
>
>
> On 5/26/2011 3:29 PM, Willem Jiang wrote:
>>
>> Hi Jim,
>>
>> Claus give some inputs on the CAMEL-4008, one of his concern is letting
>> the user setting the ReplyTo property will cause some memory leak, as
>> camel-jms will start a jms listener per reply queue and only release it when
>> the camel context is shut down,
>>
>> I don't know why you want to set the ReplyTo property at the run time, it
>> will not affect the JMS consumer as the ReplyTo will be set with a tempera
>> queue name by default. And You can also set the ReplyTo to persistent queue
>> through the JMS URI option, if you want to use persistent queue to store the
>> reply message.
>>
>> So I'm afraid I had to revert the change shortly.
>>
>> Any thought ?
>>
>> On 5/24/11 5:13 PM, Willem Jiang wrote:
>>>
>>> Hi,
>>>
>>> I created a JIRA[1] for this issue, and also committed quick fix for it.
>>> It should be part of Camel 2.8.0, and you can using header name
>>> "camelJmsReplyTo" to set the jms replyTo property.
>>>
>>> [1]https://issues.apache.org/jira/browse/CAMEL-4008
>>>
>>> On 5/24/11 12:47 PM, Willem Jiang wrote:
>>>>
>>>> I can reproduce the error and will dig the code for it.
>>>>
>>>> On 5/24/11 11:29 AM, Jim Newsham wrote:
>>>>>
>>>>> I have tried "queue:myqueue" and the result is the same. I tried both:
>>>>>
>>>>> //exchange.getIn().setHeader("JMSReplyTo",
>>>>> ActiveMQConverter.toDestination("queue:myqueue"));
>>>>> exchange.getIn().setHeader("JMSReplyTo", "queue:myqueue");
>>>>>
>>>>> Thanks,
>>>>> Jim
>>>>>
>>>>> On 5/23/2011 5:21 PM, Willem Jiang wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Can you change the queue name to queue:myqueue?
>>>>>>
>>>>>> On 5/24/11 11:13 AM, Jim Newsham wrote:
>>>>>>>
>>>>>>> Hi Willem,
>>>>>>>
>>>>>>> Unfortunately I do not know the reply-to queue name at the time
the
>>>>>>> route is created, which is why I hoped to set the reply-to header
>>>>>>> dynamically. Are you saying that my example should work if I
used a
>>>>>>> javax.jms.Destination? I have tried the following but the result
is
>>>>>>> the
>>>>>>> same as before.
>>>>>>>
>>>>>>> public void process(Exchange exchange) throws Exception {
>>>>>>> exchange.getIn().setHeader("JMSReplyTo",
>>>>>>> ActiveMQConverter.toDestination("queue://myqueue"));
>>>>>>> }
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Jim
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>



-- 
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
CamelOne 2011: http://fusesource.com/camelone2011/
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Mime
View raw message