Hi
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:
http://activemq.apache.org/camel/error-handler.html
Med venlig hilsen
Claus Ibsen
......................................
Silverbullet
Skovsgårdsvænget 21
8362 Hørning
Tlf. +45 2962 7576
Web: www.silverbullet.dk
-----Original Message-----
From: harinair [mailto:[EMAIL PROTECTED]
Sent: 1. oktober 2008 00:42
To: camel-user@activemq.apache.org
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:
from('some-queue').recipientList(header('myRoute')).to(myProcess);
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:
from('some-queue').intercept('myDelegateProcessor').recipientList(header('myRoute'));
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?
Regards,
Hari Gangadharan
Claus Ibsen wrote:
>
> I think the http result code is added as a header:
> HttpProducer.HTTP_RESPONSE_CODE
>
> http://activemq.apache.org/camel/http.html
>
>
>
> Med venlig hilsen
>
> Claus Ibsen
> ......................................
> Silverbullet
> Skovsgårdsvænget 21
> 8362 Hørning
> Tlf. +45 2962 7576
> Web: www.silverbullet.dk
>
> -----Original Message-----
> From: harinair [mailto:[EMAIL PROTECTED]
> Sent: 30. september 2008 00:28
> To: camel-user@activemq.apache.org
> 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
>>> 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.
>
>
>
--
View this message in context:
http://www.nabble.com/Camel-HTTP-producer-successful-on-404--tp19681729s22882p19751168.html
Sent from the Camel - Users mailing list archive at Nabble.com.
