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: Camel 2.0-M3 swalllowing exceptions?
Date Thu, 06 Aug 2009 03:56:50 GMT
On Wed, Aug 5, 2009 at 9:01 PM, J_Racker<john.madrid@rackspace.com> wrote:
>
> Thanks so much,
>
> This is my own code.  The reason I'm dealing with camel at this level is
> because I'm writing my own Component/Endpoint/Consumer combo for connecting
> to a NimBUS Queue.  This code is from the callback method which acts sort of
> like a message listener.
>

Fantastic. Great that you try to write your own component.
A bit info here:
http://camel.apache.org/writing-components.html
http://camel.apache.org/how-do-i-add-a-component.html

You can also use
exchange.isFailed() to test whether the exchange did not succeed.
However then in theory it could also have a FAULT message set.


> John
>
>
> Claus Ibsen-2 wrote:
>>
>> Hi
>>
>> On Wed, Aug 5, 2009 at 8:44 PM, J_Racker<john.madrid@rackspace.com> wrote:
>>>
>>> I'm having a problem when setting up a route in camel.  In the process of
>>> debugging a new camel route I noticed that I could not connect to my
>>> Activemq Broker because of authentication.  So during the route when the
>>> message is sent to the queue, the following exception is thrown
>>> (javax.jms.JMSException: User broker is not authorized to write to:
>>> queue://).
>>>
>>> According to the documentation if an exception happens during the route
>>> in
>>> camel 2, the exception should be propagated to the caller.  Here is the
>>> code
>>> that initiates the exchange
>>>
>>> Exchange exchange = getEndpoint().createExchange();
>>> exchange.getIn().setBody(some_data);
>>> exchange.getIn().setHeader(MyHeader, MyHeaderValue);
>>>
>>> try {
>>>        this.getProcessor().process(exchange);
>>> } catch (Exception e) {
>>>        log.error("Caught Exception during message forwarding.", e);
>>>        handleException(e);
>>> }
>>
>> I assume this is you own code?
>> And you use a processor for that? That is very low level to operate.
>>
>> If so you should add a check for exchange.getException() != null as
>> the exception will be stored there
>>
>> So you can actually change the code to
>>
>>         this.getProcessor().process(exchange);
>>         if (exchange.getException() != null) {
>>           Exception e = exchange.getException();
>>           log.error("Caught Exception during message forwarding.", e);
>>           handleException(e);
>>         }
>>
>>
>> If you use some client API or (non processor) Camel will throw back
>> the caused exception to you.
>>
>> Gotta go.
>>
>>
>>>
>>> The problem I'm seeing is that even though the route throws an exception
>>> this process method returns as if everything happened fine and my catch
>>> block isn't triggered.
>>>
>>> In tracing through the camel code, I noticed that in the
>>> RedeliveryErrorHandler class on line 241 it calls:
>>>
>>> OnExceptionDefinition exceptionPolicy = getExceptionPolicy(exchange, e);
>>>
>>> which sets exceptionPolicy to null because I haven't set any exception
>>> policies.  According to the docs the default behavior should be to throw
>>> the
>>> exception to the caller, but instead it appears that because there is no
>>> exceptionPolicy that the handler simply returns after logging the failure
>>>
>>> String msg = "Failed delivery for exchangeId: " +
>>> exchange.getExchangeId()
>>>                + ". On delivery attempt: " + data.redeliveryCounter +
"
>>> caught: " + e;
>>> logFailedDelivery(true, exchange, msg, data, e);
>>>
>>> So in an attempt to solve this I added the following line to my route
>>> builder:
>>>
>>> onException(java.lang.Exception.class).throwException(new
>>> RuntimeException("Exception in message processing"));
>>>
>>> Now, when in the RedeliveryErrorHandler, this new exception policy is
>>> assigned and the failure processor is set to throw the RuntimeException.
>>> However, the failure processor is also wrapped by the
>>> RedeliveryErrorHandler
>>> and when it throws the RuntimeException, the RedeliveryErrorHandler
>>> immediately grabs it, logs it, eats it, and returns as if everything is
>>> fine.
>>>
>>> Am I using this exception handling framework in some way that it isn't
>>> meant
>>> to be used?  Is there a bug in the RedeliveryErrorHandler?  Any help
>>> would
>>> be appreciated.
>>>
>>> Thank You
>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Camel-2.0-M3-swalllowing-exceptions--tp24834025p24834025.html
>>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>>
>>>
>>
>>
>>
>> --
>> Claus Ibsen
>> Apache Camel Committer
>>
>> Open Source Integration: http://fusesource.com
>> Blog: http://davsclaus.blogspot.com/
>> Twitter: http://twitter.com/davsclaus
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Camel-2.0-M3-swalllowing-exceptions--tp24834025p24834267.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>



-- 
Claus Ibsen
Apache Camel Committer

Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus

Mime
View raw message