deadletter verse recipientList design issue

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

deadletter verse recipientList design issue

BASE Logic, Inc.
I have not gotten any solutions to my design issue, so I am stepping back to
see if there is another way to accomplish what I am trying to do.

I want to check for message exceptions such as transformation or database
errors processing incoming messages. My initial thought was to process them
as deadletters and that works but I have no way of knowing what error
message that actually occurred and no way to take that error message and add
it to the header so the original message is not modified.

So what else can I do here?

I could just wrap every block in a try/catch, then if I catch and error, and
the error to the header, change the destination, and rout to the dynamic
recipientList right?



--
---
Thank You…

Mick Knutson
BASE Logic, inc.
(415) 354-4215

Website: http://baselogic.com
Blog: http://baselogic.com/blog
BLiNC Magazine: http://blincmagazine.com
Linked IN: http://linkedin.com/in/mickknutson
DJ Mick: http://djmick.com
MySpace: http://myspace.com/mickknutson
Vacation Rental: http://tahoe.baselogic.com
Reply | Threaded
Open this post in threaded view
|

RE: deadletter verse recipientList design issue

Claus Ibsen
Hi

If you are using the DeadLetterChannel in Camel it does in fact
- remove the exception: exchange.setException(null)
- but its stored elsewhere: exchange.setProperty(FAILURE_HANDLED_PROPERTY, exchange.getException()); See the source code for DLC.

So you should be able to get the original caused exception even while handling the failure in your own processor code.

We should probably support an easier way to get this information. Somekind of method on the exchange.

Please feel free to create a ticket for this. Somekind of public API method on Exchange to get this information:
- is this exchange currently being failure handled
- what was the original cause of this failure



You can also do the per exception route:

// regular deadletterchannel here

exception(MySuperDuperException.class).to("bean:handleMySuperDuperException);
exception(MyCoolException.class).to("bean:handleMyCoolException);

// and then the regular routing stuff here



Med venlig hilsen
 
Claus Ibsen
......................................
Silverbullet
Skovsgårdsvænget 21
8362 Hørning
Tlf. +45 2962 7576
Web: www.silverbullet.dk

-----Original Message-----
From: Mick Knutson [mailto:[hidden email]]
Sent: 2. oktober 2008 18:37
To: Camel
Subject: deadletter verse recipientList design issue

I have not gotten any solutions to my design issue, so I am stepping back to
see if there is another way to accomplish what I am trying to do.

I want to check for message exceptions such as transformation or database
errors processing incoming messages. My initial thought was to process them
as deadletters and that works but I have no way of knowing what error
message that actually occurred and no way to take that error message and add
it to the header so the original message is not modified.

So what else can I do here?

I could just wrap every block in a try/catch, then if I catch and error, and
the error to the header, change the destination, and rout to the dynamic
recipientList right?



--
---
Thank You...

Mick Knutson
BASE Logic, inc.
(415) 354-4215

Website: http://baselogic.com
Blog: http://baselogic.com/blog
BLiNC Magazine: http://blincmagazine.com
Linked IN: http://linkedin.com/in/mickknutson
DJ Mick: http://djmick.com
MySpace: http://myspace.com/mickknutson
Vacation Rental: http://tahoe.baselogic.com
Reply | Threaded
Open this post in threaded view
|

Re: deadletter verse recipientList design issue

BASE Logic, Inc.
Can you explain the difference scope of:

        *errorHandler(deadLetterChannel().exceptionPolicyStrategy(new
ChangeRequestExceptionPolicy()));

        onException(ChangeRequestExceptionPolicy.class)
                .maximumRedeliveries(1)
                .setHeader("ERROR_INFO", constant("Damm my policy
exception"))
                .to(Constants.CHANNEL_GG_CS_CR_DEFAULT_ERROR);
*

*verse using:*

        *from(Constants.CHANNEL_GG_CS_CR_ADD)
                .errorHandler(
                        deadLetterChannel(Constants.
CHANNEL_GG_CS_CR_ADD_ERROR)
                                .loggingLevel(LoggingLevel.INFO)
                )
                .processRef("changeRequestProcessor**")
                .recipientList(header(Constants.REQUEST_DESTINATION));*



I am finding that the second example I gave is not working.

When there is an error in my *changeRequestProcessor*, the error gets routed
to *CHANNEL_GG_CS_CR_DEFAULT_ERROR instead of
**CHANNEL_GG_CS_CR_ADD_ERRORas I would expect.
*



On Thu, Oct 2, 2008 at 9:51 AM, Claus Ibsen <[hidden email]> wrote:

> Hi
>
> If you are using the DeadLetterChannel in Camel it does in fact
> - remove the exception: exchange.setException(null)
> - but its stored elsewhere: exchange.setProperty(FAILURE_HANDLED_PROPERTY,
> exchange.getException()); See the source code for DLC.
>
> So you should be able to get the original caused exception even while
> handling the failure in your own processor code.
>
> We should probably support an easier way to get this information. Somekind
> of method on the exchange.
>
> Please feel free to create a ticket for this. Somekind of public API method
> on Exchange to get this information:
> - is this exchange currently being failure handled
> - what was the original cause of this failure
>
>
>
> You can also do the per exception route:
>
> // regular deadletterchannel here
>
>
> exception(MySuperDuperException.class).to("bean:handleMySuperDuperException);
> exception(MyCoolException.class).to("bean:handleMyCoolException);
>
> // and then the regular routing stuff here
>
>
>
> Med venlig hilsen
>
> Claus Ibsen
> ......................................
> Silverbullet
> Skovsgårdsvænget 21
> 8362 Hørning
> Tlf. +45 2962 7576
> Web: www.silverbullet.dk
>
> -----Original Message-----
> From: Mick Knutson [mailto:[hidden email]]
> Sent: 2. oktober 2008 18:37
> To: Camel
> Subject: deadletter verse recipientList design issue
>
> I have not gotten any solutions to my design issue, so I am stepping back
> to
> see if there is another way to accomplish what I am trying to do.
>
> I want to check for message exceptions such as transformation or database
> errors processing incoming messages. My initial thought was to process them
> as deadletters and that works but I have no way of knowing what error
> message that actually occurred and no way to take that error message and
> add
> it to the header so the original message is not modified.
>
> So what else can I do here?
>
> I could just wrap every block in a try/catch, then if I catch and error,
> and
> the error to the header, change the destination, and rout to the dynamic
> recipientList right?
>
>
>
> --
> ---
> Thank You...
>
> Mick Knutson
> BASE Logic, inc.
> (415) 354-4215
>
> Website: http://baselogic.com
> Blog: http://baselogic.com/blog
> BLiNC Magazine: http://blincmagazine.com
> Linked IN: http://linkedin.com/in/mickknutson
> DJ Mick: http://djmick.com
> MySpace: http://myspace.com/mickknutson
> Vacation Rental: http://tahoe.baselogic.com
>



--
---
Thank You…

Mick Knutson
BASE Logic, inc.
(415) 354-4215

Website: http://baselogic.com
Blog: http://baselogic.com/blog
BLiNC Magazine: http://blincmagazine.com
Linked IN: http://linkedin.com/in/mickknutson
DJ Mick: http://djmick.com
MySpace: http://myspace.com/mickknutson
Vacation Rental: http://tahoe.baselogic.com