On 07/11/2007, Roman Kalukiewicz <[EMAIL PROTECTED]> wrote:
> Hello!
>
> I'm not sure if I found a bug or it is just a 'feature'.
>
> Let's create following flow (where exceptionThrower processor just
> throws IllegalArgumentException - it is taken from ExceptionTest):
>
> exception(IllegalArgumentException.class).to("mock:exception");
>
> from("direct:start2").to("direct:intermediate").to("mock:result");
>
> from("direct:intermediate").
> setBody(constant("<some-value/>")).
> process(exceptionThrower).to("mock:resuilt");
>
> The question is what should happen here when you send something to
> direct:start2?
> a) exception is intercepted by global exception handler and there is
> only one message delivered to mock:exception
> b) exception is intercepted in direct:intermediate flow, delivered to
> mock:exception and then it is claimed as handled and is delivered to
> mock:result (first pipeline)
> c) exception is intercepted in direct:intermediate flow, delivered to
> mock:exception, then pipeline is broken and returns to first pipeline
> and as we see error once again it is handled second time (delivered to
> mock:exception)
>
> In current implementation it is even more complicated (I assume buggy):
> Message is delivered to mock:exception twice BUT if we change the
> order of 'setBody()' clause and process() clause it delivered to
> mock:exception only once. It is because DeadLetterChannel that
> controls those exceptions set FAILURE_HANDLED_PROPERTY on the exchange
> that marks failure as handled.
> The problem is that if pipeline is involved it will copy its result to
> original exchange and it doesn't copy properties BUT at first step of
> pipeline it uses original exchange so every property set at the first
> step of pipeline is propagated back.
>
> I wanted to fix this problem and my belief is that correct behavior in
> this scenario is a) but I don't really know what is the exact meaning
> of exception() clause.Great investigation Romek! You're right there's been a few gremlins in this code. Both Hadrian. Hiram and myself have patched the exception handling/pipeline code over the last few weeks and its definitely looking in much better shape now. I've tried creating a JUnit test case testing all of the scenarios you mention and I think things are working fine. Here's the test case... http://svn.apache.org/repos/asf/activemq/camel/trunk/camel-core/src/test/java/org/apache/camel/issues/RomeksExceptionTest.java So I think this issue may be resolved now? Or is it a case of my test case not correctly executing the exact scenario you had in mind? BTW I found the routing rules in this test case to be quite cute - using the dynamic RecipientList depending on message header to test out different sub-routes. Its way simpler than having complex if statements inside the route definition code. -- James ------- http://macstrac.blogspot.com/ Open Source Integration http://open.iona.com
