2008/1/24, DominicTulley <[EMAIL PROTECTED]>:
>
> I disabled the InOut thing by using:
>
> from("activemq.A?disableReplyTo=true").setHeader(...).to("activemq.B");
>
> This appears to have resolved my immediate issue (in that the messages are
> no longer expiring).
> Is this correct, or should I also put the disableReplyTo on the "to"
> portion?It really depends on what you want to happen. Now (as far as I guess) it goes this way (InOnly == one-way): client setting ReplyTo -> A -> Camel -> B -> server -> ReplyTo originally set When you disableReplyTo it means that you don't want any response to be sent (by Camel flow) to ReplyTo originally specified at input - this ReplyTo is anyway propagated to server and the server responds to JMSReplyTo. When you had JMSReplyTo at the very beginning (without disableReplyTo) Camel wanted to respond to the message _itself_ so it was using InOut mode. According to InOut mode, when you send to B, Camel sets CorrelationID and JMSReplyTo so it informs the server side about the queue and Correlation it waits for a response on. in InOut mode it should work as: client setting ReplyTo -> A -> Camel (sets its own JMSReplyTo) -> B -> server -> ReplyTo set by Camel -> Camel -> ReplyTo specified at A -> client So what I guess: Camel flow was previously working in InOut, so message was sent to B and Camel was waiting for a response on its own JMSReplyTo (associated with the message), but the server was responding to original JMSReplyTo set by client side. Camel had no response, so timeout was thrown, and redelivery was triggered. > I'd also be interested in what you make of the concurrency timeout > exception. I've seen various other messages that talk about this exception, > but it's not clear to me if it's expected or if it's an indicator that some > code isn't behaving properly. I believe that an answer to this question is basically in the answer for the first part ;) Roman
