camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Claus Ibsen">
Subject RE: Camel HTTP producer successful on 404?
Date Wed, 01 Oct 2008 06:15:54 GMT

You can throw any exception to force a retry.

int responseCode = ..
if (responseCode == 500) {
   throw new MyRetryException();

The default error handler (= DeadLetterChannel) should kick in and retry it:

Med venlig hilsen
Claus Ibsen
Skovsgårdsvænget 21
8362 Hørning
Tlf. +45 2962 7576

-----Original Message-----
From: harinair [] 
Sent: 1. oktober 2008 00:42
Subject: RE: Camel HTTP producer successful on 404?

I am almost given up on this. Probably I am too inexperienced to word the
questions correctly. I know the HTTP Response code is added to the header -
I can check that after the HTTP component is run - for example:

In myProcess I can check the http.responseCode to figure out the response
code but what can I do to retry? According to my understanding at myprocess,
the previous process is complete - I cannot go back. I tried intercept
before the recipientList like this:
But I am not getting the responseCode in myDelegateProcessor. Am I stating
my issue properly or you guys are not getting a clue on what I am saying? 

Hari Gangadharan

Claus Ibsen wrote:
> I think the http result code is added as a header:
> Med venlig hilsen
> Claus Ibsen
> ......................................
> Silverbullet
> Skovsgårdsvænget 21
> 8362 Hørning
> Tlf. +45 2962 7576
> Web:
> -----Original Message-----
> From: harinair [] 
> Sent: 30. september 2008 00:28
> To:
> Subject: Re: Camel HTTP producer successful on 404?
> Hadrian:
> Case by case it may be different. For my case I am delivering messages to
> a
> partner using Camel just like email. I should not miss delivering any
> messages. We know address to which the messages are posted is valid. My
> requirements is to hold the messages for at least xxx hours or until the
> receiving app comes online. There may be cases I send a message and in
> that
> time partner's application is in the process of an upgrade. We cannot rule
> out 404 or 500 - I am not sure what technology or what deployment
> procedure
> they use. The thing is if I could retry after sometime and the error
> persists, best if it goes to an undeliverable queue.
> If HTTP component doesn't do that by default then that is fine. But it
> should be flexible so that as an user I should be able to control that.
> IMHO, it would be great if as an user, if I could set a header aptly named
> http.retryOnAllErrors to true for retying on all errors. Otherwise a
> header
> like http.retryOnErrors which take in a list of error codes...
> Since that is not built in to HTTP component, is there any way I can code
> so
> that I can inspect the return code and make HTTP component retry? I tried
> it
> as an intercept but it did not work.
> Thanks for the lively discussion.
> Hari Gangadharan
> Hadrian Zbarcea wrote:
>> Hi Hari,
>> Your questions/comments are welcome, keep them coming.
>> I don't think 404 or 500, could be an indication of server being  
>> down.  404 is page not found, i don't see how a retry will change  
>> that.  500 is internal server error (iirc) and I *do* see how a retry  
>> could be successful in that case.  So in my mind 404 is a fault, 500  
>> is an exception.  We have to consider things like proxies (as in  
>> ProxyPass/ProxyPassReverse or UrlRewrite for apache servers) as it may  
>> be the case that web services hide behind a web server/firewall of  
>> sorts.
>> We do have a mechanism that causes camel to treat faults and  
>> exceptions uniformly, but I hope will add a better (rule based)  
>> mechanism for handling faults later on.
>> Cheers
>> Hadrian
>> On Sep 26, 2008, at 12:21 PM, harinair wrote:
>>> Thanks a lot, Hadrian and Wilem.
>>> In my case, I have to transfer data to an external consumer using  
>>> Post. The producer works well for this case. However my requirement  
>>> is to
>>> try redelivering(with exponential backoff) for any errors including  
>>> 404 and
>>> 500 since it may be a case of consumer's server being down.
>>> I am using something like this:
>>> errorHandler(deadLetterChannel("jms:redelivery- 
>>> queue").initialRedeliveryDelay(20000)
>>> .backOffMultiplier(2).maximumRedeliveries(3).useExponentialBackOff());
>>> from 
>>> ("jms:deliveryqueue 
>>> ").recipientList(header("address")).to("bean:MyBean? 
>>> method=processIsOK");
>>> in this the header address contains something like
>>> https://myconsumer/servlet/CallbackServlet
>>> Now the problem is I find that the HTTP component will not even try
>>> redelivering for 404 and 401. It acts as if it is a successful  
>>> transport. I
>>> understand that I can check whether the delivery has failed or not.  
>>> I found
>>> out from HTTP producer code I am even able to check the response  
>>> code by
>>> looking at the http.responseCode header (Probably we should update  
>>> HTTP
>>> Component doc - I can help). But how can I make Camel try  
>>> redelivering these
>>> 404/401 messages?
>>> I am sorry if I am not explaining it properly. Since I am pretty new  
>>> in
>>> Camel, probably I am blabbering something that is totally off mark.
>>> Thanks in advance.
>>> Hari Gangadharan
> -- 
> View this message in context:
> Sent from the Camel - Users mailing list archive at

View this message in context:
Sent from the Camel - Users mailing list archive at

View raw message