Return-Path: 
 <issues-return-6818-apmail-camel-issues-archive=camel.apache.org@camel.apache.org>
X-Original-To: apmail-camel-issues-archive@minotaur.apache.org
Delivered-To: apmail-camel-issues-archive@minotaur.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id EF5FCD66B
	for <apmail-camel-issues-archive@minotaur.apache.org>;
 Wed,  7 Nov 2012 09:41:16 +0000 (UTC)
Received: (qmail 84897 invoked by uid 500); 7 Nov 2012 09:41:16 -0000
Delivered-To: apmail-camel-issues-archive@camel.apache.org
Received: (qmail 84251 invoked by uid 500); 7 Nov 2012 09:41:14 -0000
Mailing-List: contact issues-help@camel.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:issues-help@camel.apache.org>
List-Unsubscribe: <mailto:issues-unsubscribe@camel.apache.org>
List-Post: <mailto:issues@camel.apache.org>
List-Id: <issues.camel.apache.org>
Reply-To: dev@camel.apache.org
Delivered-To: mailing list issues@camel.apache.org
Received: (qmail 84203 invoked by uid 99); 7 Nov 2012 09:41:13 -0000
Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 07 Nov 2012 09:41:13 +0000
Date: Wed, 7 Nov 2012 09:41:13 +0000 (UTC)
From: "Claus Ibsen (JIRA)" <jira@apache.org>
To: issues@camel.apache.org
Message-ID: <821682996.79842.1352281273309.JavaMail.jiratomcat@arcas>
In-Reply-To: <280980307.95454.1343134955151.JavaMail.jiratomcat@issues-vm>
Subject: [jira] [Commented] (CAMEL-5464) camel-jms consumer doesn't send
 back a reply in all cases
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394


    [ https://issues.apache.org/jira/browse/CAMEL-5464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13492226#comment-13492226 ] 

Claus Ibsen commented on CAMEL-5464:
------------------------------------

I think this fix is more important, than those odd unit-tests that was needed to change.

If you do request/reply over JMS, then you would expect Camel to send back the reply always - also if the route, only do a single step like
from JMS
  to bean

So I am working on backporting this to older branches.
                
> camel-jms consumer doesn't send back a reply in all cases
> ---------------------------------------------------------
>
>                 Key: CAMEL-5464
>                 URL: https://issues.apache.org/jira/browse/CAMEL-5464
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-activemq, camel-jms
>    Affects Versions: 2.8.6, 2.9.2, 2.10.0
>            Reporter: Raul Kripalani
>            Assignee: Willem Jiang
>             Fix For: 2.9.5, 2.10.3, 2.11.0
>
>         Attachments: CAMEL-5464.patch
>
>
> In a very simple route consuming from a Camel JMS endpoint receiving InOut exchanges (i.e. JMSReplyTo header present), the endpoint will not send back replies.
> This happens because Camel JMS only returns a reply if the OUT message is set. But if the route looks like: consumer => processor, and Camel doesn't find the need to "weave in" an implicit Pipeline processor, no one will implicitly take care of mapping the IN message to an OUT message (unless the user knows about these internal aspects - but we shouldn't expect them too).
> As a result, these routes DON'T WORK...
> {code}
> <route>
>    <from uri="timer:foo?fixedRate=true&amp;period=10000" />
>    <setBody><constant>Hello Raul</constant></setBody>
>    <to uri="log:SendingRequest?showAll=true" />
>    <inOut uri="activemq:queue:test1?requestTimeout=1000" />
>    <to uri="log:ReceivedReply?showAll=true" />
> </route>
>         
> <route>
>    <from uri="activemq:queue:test1" />
>    <to uri="log:ReceivedRequest?showAll=true" />
> </route>
> {code}
> ... but just by adding an additional log endpoint to the second route (or any other thing, for that matter), it starts to work because Camel weaves in the Pipeline processor.
> Other workarounds that work:
> * -explicitly wrapping the log endpoint in a <pipeline> DSL-
> * <setBody><simple>${in.body}</simple></setBody>
> Or simply introducing anything that will force Camel to insert a Pipeline processor.
> IMHO, there are two solutions to avoid this issue:
> # Always weave in a Pipeline processor (adds overhead in simple routes and may cause regressions)
> # Adapt EndpointMessageListener to pick the IN message when the exchange is out capable and expectation of a reply exists
> I'm happy to work on a patch for Camel 2.10.1.
> *EDIT:* Just wrapping the single endpoint in <pipeline /> doesn't function as a workaround.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira