You are viewing a plain text version of this content. The canonical link for it is here.

Posted to users@camel.apache.org by "Wilson, Chad (Equity Technology)" <c....@baml.com> on 2010/12/24 11:36:36 UTC

Issue with route specific onException and jms component

Hi all

(Apologies about corporate junk at bottom of message)

I've been trying to upgrade our Camel usage to 2.5.0 and have been
scratching my head about a weird integration test failure and change in
behavior in 2.5.0 related to per-route exception handling. The issue
seems to occur when the JMS component throws an exception on a secondary
route as a side effect of processing a message on a primary route - for
some reason the exception ends up bubbling up to the primary route
rather than being caught by the ErrorHandler for the route the component
is in. Additionally, the secondary route's message ends up stuck in
flight.

The flow we're trying to achieve in this use case is:

1) Message X received on Route A
2) Do some stuff to Message X
3) Synchronously generate and send ack message Y down secondary Route B
3a) Use recipient list to dynamically decide reply endpoint
3b) Ack perhaps cannot be delivered to this endpoint for some
reason (JMS error)
3c) Handle exception somehow
4) Continue processing Message X on Route A

I've adapted this into a test case (possibly could be simpler) - the
attached passes consistently for me on Camel 2.4.0 but consistently
fails on Camel 2.5.0. Can someone explain why?

I've noted issues like https://issues.apache.org/jira/browse/CAMEL-3448
but if I remove the error handler from the primary route the exception
still bubbles back up, so I don't think it's due to this.

Is anyone able to explain this behavior? Any workaround suggestions if
it is indeed a bug? We'd prefer to stick with Camel 2.5.0 to benefit
from some enhancements to use of property placeholders and other bits
and pieces.

Many thanks
Chad

----------------------------------------------------------------------
This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited.
Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law.
The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses.

References to "Sender" are references to any subsidiary of Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this EC may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link:
http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you consent to the foregoing.

RE: Issue with route specific onException and jms component

Posted by "Wilson, Chad (Equity Technology)" <c....@baml.com>.

Argh - and now according to Nabble, my original message doesn't exist at
all. Groan. Please bear with me. Corporate email gateways are not my
friend.

------------
Hi all

The flow we're trying to achieve in this use case is:

I've adapted this into a test case (possibly could be simpler) - the
attached passes consistently for me on Camel 2.4.0 but consistently
fails on Camel 2.5.0. Can someone explain why?

Many thanks
Chad

Re: Issue with route specific onException and jms component

Posted by rkrdr <ca...@thesiglers.net>.

Yes I think there is a bug related catching exceptions that are thrown by the
jms producer.  As well, I noticed a side effect in camel 2.5.0 directly
related to the asynchronous routing engine is that exceptions thrown (i.e.
not specifically set on the exchange) in an aggregator aggregating
request/reply from a jms endpoint are no longer handled in the onException
for the route.  If on the other hand, the aggregator code is surrounded by
try/catch and sets the exception on the exchange...the onException handler
will be invoked.  The requirement to set the exception on the exchange is
documented here:

http://camel.apache.org/asynchronous-processing.html  

But this appears to have became a _requirement_ after moving to 2.5 due to
the asynchronous routing engine changes for jms.  If I revert back to using
the synchronous=true on the jms producer, exceptions thrwon from the
aggregator are picked up in the onException whether or not set on the
exchange directly.  I'm concerned about other places in the route where
exceptions may be thrown (i.e. the jms producer itself)
I have not used doTry/doCatch construct thus far in camel.






-- 
View this message in context: http://camel.465427.n5.nabble.com/RE-Issue-with-route-specific-onException-and-jms-component-tp3317547p3403953.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Issue with route specific onException and jms component

Posted by Chad Wilson <c....@baml.com>.

Genius! You appear to be absolutely correct. I've been meaning to come back
to this to log a bug properly, so thanks for the kick.

My earlier JUnit test I attached now passes with ?synchronous=true on the
JMS endpoint; and of course explains why I could not replicate the behaviour
with non-JMS endpoints.

Which leads to the further question - is this still a bug? Why with the
Asynchronous Routing Engine does the exception bubble up to the "parent"
route?

-- 
View this message in context: http://camel.465427.n5.nabble.com/RE-Issue-with-route-specific-onException-and-jms-component-tp3317547p3402793.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Issue with route specific onException and jms component

Posted by rkrdr <ca...@thesiglers.net>.

Is this related to the asynchronous routing engine for jms producer
introduced in camel 2.5?  As it relates to exceptions "thrown" from that
producer?  You might try the test again disabling the asynchronous engine
for the jms producer ( set ?synchronous=true) to see if the result changes.  
Just a thought. 

http://camel.apache.org/asynchronous-routing-engine.html

and 

http://camel.apache.org/asynchronous-processing.html
-- 
View this message in context: http://camel.465427.n5.nabble.com/RE-Issue-with-route-specific-onException-and-jms-component-tp3317547p3400815.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Issue with route specific onException and jms component

Posted by Chad Wilson <c....@baml.com>.

Claus Ibsen-2 wrote:
> 
> So where does your exception occur?
> 
> And where do you expect Camel to react?
> 

The exception is engineered by the test to occur inside the JMS Component
when trying to establish a connection to an invalid host. While my test case
uses the TIBCO connection factory, the ActiveMQ one does the same, and I'm
sure other exceptions at the JMS endpoint (A+A errors, topic/queue doesn't
exist, etc) cause similar behaviour.

I expect Camel to catch the exception and pass it to the handler inside the
secondary route (the one starting with direct:secondaryEntry) since it has a
blanket onException(Exception.class) handler. Thus the message should be
redirected (in my test) to mock:secondaryErrors - not bubbling back up to
the primary route and going to mock:mainErrors, as it currently is, without
touching the secondary route's error handler at all.

I can't work out in exactly which circumstances this is an issue - I think
it's something to do with either the recipient list or the jms component or
interaction between the two, as if I change the route to throw exceptions
from other stages in the secondary route they seem to be handled correctly
inside that route.

Cheers - hope you're all having a good holiday break :)

Chad
-- 
View this message in context: http://camel.465427.n5.nabble.com/RE-Issue-with-route-specific-onException-and-jms-component-tp3317547p3319043.html
Sent from the Camel - Users mailing list archive at Nabble.com.

RE: Issue with route specific onException and jms component

Posted by "Wilson, Chad (Equity Technology)" <c....@baml.com>.

Attachment appear to be nuked - here's the test I'm working with.

-------------------------------------------------------------
import org.apache.camel.EndpointInject;
import org.apache.camel.Produce;
import org.apache.camel.ProducerTemplate;
import org.apache.camel.builder.RouteBuilder;
import org.apache.camel.component.jms.JmsComponent;
import org.apache.camel.component.jms.JmsConfiguration;
import org.apache.camel.component.mock.MockEndpoint;
import org.apache.camel.test.junit4.CamelTestSupport;
import org.junit.Test;

import com.tibco.tibjms.TibjmsConnectionFactory;

public class Camel25ExceptionChangeTest extends CamelTestSupport {

	@Produce(uri = "direct:entry")
	protected ProducerTemplate entry;

	@Produce(uri = "direct:secondaryEntry")
	protected ProducerTemplate secondaryEntry;

	@EndpointInject(uri = "mock:mainEnd")
	protected MockEndpoint mainEnd;

	@EndpointInject(uri = "mock:secondaryEnd")
	protected MockEndpoint secondaryEnd;

	@EndpointInject(uri = "mock:mainErrors")
	protected MockEndpoint mainErrors;

	@EndpointInject(uri = "mock:secondaryErrors")
	protected MockEndpoint secondaryErrors;

	@Override
	protected RouteBuilder createRouteBuilder() throws Exception {
		return new RouteBuilder() {
			@Override
			public void configure() throws Exception {

				// Primary route (like an input route)
				from("direct:entry")
					.onException(Exception.class)
						.handled(true)
						.to("mock:mainErrors")
						.end()

					// This bean generates a new
message to go down the secondary route over JMS
					.bean(new
ProducingBean(secondaryEntry))
					.to("mock:mainEnd")
					.routeId("mainRoute");

				// Secondary route that is invoked by
producing bean
				from("direct:secondaryEntry")
					.onException(Exception.class)
						.handled(true)
	
.to("mock:secondaryErrors")
						.end()
	
.recipientList(simple("jms:topic:SOMETOPIC"))
					.to("mock:secondaryEnd")
					.routeId("secondaryRoute");
			}
		};
	}

	@Test
	public void testExceptionHandlingChanges() throws Exception {

		// Create a JMS component with an invalid host name
		context.addComponent("jms", new JmsComponent(new
JmsConfiguration(new
TibjmsConnectionFactory("tcp://hostthatdoesntexist:7222"))));

		// Expect original mesage to be correctly delivered
since error on secondary route is handled inside that route
		mainEnd.expectedMessageCount(1);
		mainErrors.expectedMessageCount(0);

		// Expect an error on this route generated from jms
component
		secondaryEnd.expectedMessageCount(0);
		secondaryErrors.expectedMessageCount(1);

		entry.sendBody("message1");

		assertMockEndpointsSatisfied();
		
		assertEquals("Expect no messages stuck in flight...", 0,
context.getInflightRepository().size());
	}

	public static class ProducingBean {

		private ProducerTemplate sendTo;

		public ProducingBean(ProducerTemplate sendTo) {
			this.sendTo = sendTo;
		}

		public void produce(String message) {
			sendTo.sendBody("REPLY-TO-"+message);
		}
	}

}

----------------------------------------------------------------------
This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. 
Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law. 
The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses. 

References to "Sender" are references to any subsidiary of Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this EC may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link: 
http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you consent to the foregoing.

Re: Issue with route specific onException and jms component

Posted by Claus Ibsen <cl...@gmail.com>.

So where does your exception occur?

And where do you expect Camel to react?


On Fri, Dec 24, 2010 at 1:12 PM, Wilson, Chad (Equity Technology)
<c....@baml.com> wrote:
> Hi Claus
>
> Just tried on 2.6-SNAPSHOT and get the same behavior on that test, unfortunately :(
>
> Chad
>
> -----Original Message-----
> From: Claus Ibsen [mailto:claus.ibsen@gmail.com]
> Sent: Friday, 24 December 2010 7:04 p.m.
> To: users@camel.apache.org
> Subject: Re: Issue with route specific onException and jms component
>
> Hi
>
> Try with 2.6-SNAPSHOT as we have fixed some issues with route scoped onException
>
>
> On Fri, Dec 24, 2010 at 11:36 AM, Wilson, Chad (Equity Technology)
> <c....@baml.com> wrote:
>> Hi all
>>
>> (Apologies about corporate junk at bottom of message)
>>
>> I've been trying to upgrade our Camel usage to 2.5.0 and have been
>> scratching my head about a weird integration test failure and change in
>> behavior in 2.5.0 related to per-route exception handling. The issue
>> seems to occur when the JMS component throws an exception on a secondary
>> route as a side effect of processing a message on a primary route - for
>> some reason the exception ends up bubbling up to the primary route
>> rather than being caught by the ErrorHandler for the route the component
>> is in. Additionally, the secondary route's message ends up stuck in
>> flight.
>>
>> The flow we're trying to achieve in this use case is:
>>
>> 1) Message X received on Route A
>> 2) Do some stuff to Message X
>> 3) Synchronously generate and send ack message Y down secondary Route B
>>        3a) Use recipient list to dynamically decide reply endpoint
>>        3b) Ack perhaps cannot be delivered to this endpoint for some
>> reason (JMS error)
>>        3c) Handle exception somehow
>> 4) Continue processing Message X on Route A
>>
>> I've adapted this into a test case (possibly could be simpler) - the
>> attached passes consistently for me on Camel 2.4.0 but consistently
>> fails on Camel 2.5.0. Can someone explain why?
>>
>> I've noted issues like https://issues.apache.org/jira/browse/CAMEL-3448
>> but if I remove the error handler from the primary route the exception
>> still bubbles back up, so I don't think it's due to this.
>>
>> Is anyone able to explain this behavior? Any workaround suggestions if
>> it is indeed a bug? We'd prefer to stick with Camel 2.5.0 to benefit
>> from some enhancements to use of property placeholders and other bits
>> and pieces.
>>
>> Many thanks
>> Chad
>>
>> ----------------------------------------------------------------------
>> This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited.
>> Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law.
>> The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses.
>>
>> References to "Sender" are references to any subsidiary of Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this EC may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link:
>> http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you consent to the foregoing.
>>
>
>
>
> --
> 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/
>
> ----------------------------------------------------------------------
> This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited.
> Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law.
> The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses.
>
> References to "Sender" are references to any subsidiary of Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this EC may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link:
> http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you consent to the foregoing.
>



-- 
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/

RE: Issue with route specific onException and jms component

Posted by "Wilson, Chad (Equity Technology)" <c....@baml.com>.

Hi Claus

Just tried on 2.6-SNAPSHOT and get the same behavior on that test, unfortunately :(

Chad

-----Original Message-----
From: Claus Ibsen [mailto:claus.ibsen@gmail.com] 
Sent: Friday, 24 December 2010 7:04 p.m.
To: users@camel.apache.org
Subject: Re: Issue with route specific onException and jms component

Hi

Try with 2.6-SNAPSHOT as we have fixed some issues with route scoped onException


On Fri, Dec 24, 2010 at 11:36 AM, Wilson, Chad (Equity Technology)
<c....@baml.com> wrote:
> Hi all
>
> (Apologies about corporate junk at bottom of message)
>
> I've been trying to upgrade our Camel usage to 2.5.0 and have been
> scratching my head about a weird integration test failure and change in
> behavior in 2.5.0 related to per-route exception handling. The issue
> seems to occur when the JMS component throws an exception on a secondary
> route as a side effect of processing a message on a primary route - for
> some reason the exception ends up bubbling up to the primary route
> rather than being caught by the ErrorHandler for the route the component
> is in. Additionally, the secondary route's message ends up stuck in
> flight.
>
> The flow we're trying to achieve in this use case is:
>
> 1) Message X received on Route A
> 2) Do some stuff to Message X
> 3) Synchronously generate and send ack message Y down secondary Route B
>        3a) Use recipient list to dynamically decide reply endpoint
>        3b) Ack perhaps cannot be delivered to this endpoint for some
> reason (JMS error)
>        3c) Handle exception somehow
> 4) Continue processing Message X on Route A
>
> I've adapted this into a test case (possibly could be simpler) - the
> attached passes consistently for me on Camel 2.4.0 but consistently
> fails on Camel 2.5.0. Can someone explain why?
>
> I've noted issues like https://issues.apache.org/jira/browse/CAMEL-3448
> but if I remove the error handler from the primary route the exception
> still bubbles back up, so I don't think it's due to this.
>
> Is anyone able to explain this behavior? Any workaround suggestions if
> it is indeed a bug? We'd prefer to stick with Camel 2.5.0 to benefit
> from some enhancements to use of property placeholders and other bits
> and pieces.
>
> Many thanks
> Chad
>
> ----------------------------------------------------------------------
> This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited.
> Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law.
> The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses.
>
> References to "Sender" are references to any subsidiary of Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this EC may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link:
> http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you consent to the foregoing.
>



-- 
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/

----------------------------------------------------------------------
This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. 
Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law. 
The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses. 

References to "Sender" are references to any subsidiary of Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this EC may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link: 
http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you consent to the foregoing.

Re: Issue with route specific onException and jms component

Posted by Claus Ibsen <cl...@gmail.com>.

Hi

Try with 2.6-SNAPSHOT as we have fixed some issues with route scoped onException


On Fri, Dec 24, 2010 at 11:36 AM, Wilson, Chad (Equity Technology)
<c....@baml.com> wrote:
> Hi all
>
> (Apologies about corporate junk at bottom of message)
>
> I've been trying to upgrade our Camel usage to 2.5.0 and have been
> scratching my head about a weird integration test failure and change in
> behavior in 2.5.0 related to per-route exception handling. The issue
> seems to occur when the JMS component throws an exception on a secondary
> route as a side effect of processing a message on a primary route - for
> some reason the exception ends up bubbling up to the primary route
> rather than being caught by the ErrorHandler for the route the component
> is in. Additionally, the secondary route's message ends up stuck in
> flight.
>
> The flow we're trying to achieve in this use case is:
>
> 1) Message X received on Route A
> 2) Do some stuff to Message X
> 3) Synchronously generate and send ack message Y down secondary Route B
>        3a) Use recipient list to dynamically decide reply endpoint
>        3b) Ack perhaps cannot be delivered to this endpoint for some
> reason (JMS error)
>        3c) Handle exception somehow
> 4) Continue processing Message X on Route A
>
> I've adapted this into a test case (possibly could be simpler) - the
> attached passes consistently for me on Camel 2.4.0 but consistently
> fails on Camel 2.5.0. Can someone explain why?
>
> I've noted issues like https://issues.apache.org/jira/browse/CAMEL-3448
> but if I remove the error handler from the primary route the exception
> still bubbles back up, so I don't think it's due to this.
>
> Is anyone able to explain this behavior? Any workaround suggestions if
> it is indeed a bug? We'd prefer to stick with Camel 2.5.0 to benefit
> from some enhancements to use of property placeholders and other bits
> and pieces.
>
> Many thanks
> Chad
>
> ----------------------------------------------------------------------
> This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited.
> Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law.
> The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses.
>
> References to "Sender" are references to any subsidiary of Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this EC may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link:
> http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you consent to the foregoing.
>



-- 
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/