camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From harinair <har...@hotmail.com>
Subject Re: Camel HTTP producer successful on 404?
Date Mon, 29 Sep 2008 22:27:45 GMT

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  
>> HTTP/HTTPS
>> 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: http://www.nabble.com/Camel-HTTP-producer-successful-on-404--tp19681729s22882p19732928.html
Sent from the Camel - Users mailing list archive at Nabble.com.


Mime
View raw message