You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by harinair <ha...@hotmail.com> on 2008/09/26 04:56:29 UTC

Camel HTTP producer successful on 404?

Hi All:

When I was testing with Camel, I noticed that the HTTP producer sends
messages to HTTP call back services well but on a 404 or 401 it does not do
retries? Is that the same case for 500 "Server error" too? Is there any way
I can modify this so that it will retry again for all response code other
than 200 OK? In other words any response other than 200 should be an error.

All replies will be greatly appreciated.

Regards,
Hari Gangadharan
-- 
View this message in context: http://www.nabble.com/Camel-HTTP-producer-successful-on-404--tp19681729s22882p19681729.html
Sent from the Camel - Users mailing list archive at Nabble.com.


RE: Camel HTTP producer successful on 404?

Posted by Claus Ibsen <ci...@silverbullet.dk>.
Hi

It should retry from: from('some-queue') and thus retry the HTTP or whatever endpoint you had in the recipientList(header('myRoute')

Throwing the exception should propagate all the way back to DeadLetterChannel that will catch this and do the redelivery.

What happens in your case?



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:hari_g@hotmail.com] 
Sent: 1. oktober 2008 18:54
To: camel-user@activemq.apache.org
Subject: RE: Camel HTTP producer successful on 404?


Claus:
So my worry is... in the following route:
errorHandler(deadLetterChannel("jms:dead-letter-queue")
    	.initialRedeliveryDelay(20000)
       
backOffMultiplier(2).maximumRedeliveries(5).useExponentialBackOff());
from('some-queue').recipientList(header('myRoute')).to(myProcess);
My understanding was that if I throw an exception in myProcess then it will
retry only that process - right? Will the retry start from the beginning of
the route? If not where? I felt like it is retrying only myProcess which
comes after the HTTP component... So no retry in HTTP happens. Does this
make sense or my observations where wrong?

Hari Gangadharan


Claus Ibsen wrote:
> 
> 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:hari_g@hotmail.com] 
> 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:hari_g@hotmail.com] 
>> 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.
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Camel-HTTP-producer-successful-on-404--tp19681729s22882p19764723.html
Sent from the Camel - Users mailing list archive at Nabble.com.


RE: Camel HTTP producer successful on 404?

Posted by harinair <ha...@hotmail.com>.
Claus:
So my worry is... in the following route:
errorHandler(deadLetterChannel("jms:dead-letter-queue")
    	.initialRedeliveryDelay(20000)
       
backOffMultiplier(2).maximumRedeliveries(5).useExponentialBackOff());
from('some-queue').recipientList(header('myRoute')).to(myProcess);
My understanding was that if I throw an exception in myProcess then it will
retry only that process - right? Will the retry start from the beginning of
the route? If not where? I felt like it is retrying only myProcess which
comes after the HTTP component... So no retry in HTTP happens. Does this
make sense or my observations where wrong?

Hari Gangadharan


Claus Ibsen wrote:
> 
> 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:hari_g@hotmail.com] 
> 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:hari_g@hotmail.com] 
>> 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.
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Camel-HTTP-producer-successful-on-404--tp19681729s22882p19764723.html
Sent from the Camel - Users mailing list archive at Nabble.com.


RE: Camel HTTP producer successful on 404?

Posted by Claus Ibsen <ci...@silverbullet.dk>.
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:hari_g@hotmail.com] 
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:hari_g@hotmail.com] 
> 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.


RE: Camel HTTP producer successful on 404?

Posted by harinair <ha...@hotmail.com>.
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:hari_g@hotmail.com] 
> 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.


RE: Camel HTTP producer successful on 404?

Posted by Claus Ibsen <ci...@silverbullet.dk>.
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:hari_g@hotmail.com] 
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.


Re: Camel HTTP producer successful on 404?

Posted by harinair <ha...@hotmail.com>.
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.


Re: Camel HTTP producer successful on 404?

Posted by Hadrian Zbarcea <hz...@gmail.com>.
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
>
>
> Hadrian Zbarcea wrote:
>>
>> Hi,
>>
>> To add to Willem's comment, there is no point in retrying for 404 for
>> example, but it makes sense to retry for codes like 500.  That means
>> that we have to enhance the camel-http component to create 2 classes
>> of errors and apply the error handle for some, but not for others.
>> This is depended on the cleanup in CAMEL-316 that will only be fully
>> resolved in the next release, and only partially (we hope) in 1.5.
>>
>> Thanks for riding the camel,
>> Hadrian
>>
>>
>> On Sep 26, 2008, at 4:00 AM, Willem Jiang wrote:
>>
>>> Hi ,
>>>
>>> Current HTTP producer will not retry if the response is 401/404/500.
>>> It just put the response back in the fault message body and it will
>>> not trigger the default error handler[1] for retring.
>>>
>>> Your application code should call exchang.isFailed() for checking
>>> the fault response.
>>>
>>> For the Camel 1.5 , we are planing to cut a RC next week. I don't
>>> think camel-http 1.5-SNAPSHOT can work with camel-core 1.4, since
>>> they are some change between the core and http component in Camel  
>>> 1.5.
>>> We are publishing the snapshot every day here[2], please take a  
>>> try :)
>>>
>>> [1] http://activemq.apache.org/camel/error-handler.html
>>> [2] http://people.apache.org/repo/m2-snapshot-repository
>>>
>>> Willem
>>>
>>> harinair wrote:
>>>> Willem:
>>>>
>>>> Thanks a lot for the quick reply. So you mean to say that the  
>>>> latest
>>>> SNAPSHOT will mark response != 200 as failed - right? I guess, that
>>>> also
>>>> means there will be retries by HTTP producer for 500 / 401/ 404  
>>>> etc.
>>>>
>>>> If that is the case then it is great. When is the 1.5 release
>>>> planned? I am
>>>> planning to go live this week for a small project and I uncovered
>>>> this bug
>>>> on a test. Is 1.5 fairly stable? Or is it recommended that I use
>>>> just the
>>>> camel-http component from the 1.5-SNAPSHOT?
>>>>
>>>> Regards,
>>>> Hari Gangadharan
>>>>
>>>>
>>>> willem.jiang wrote:
>>>>
>>>>> I just did a fixe on CAMEL-807[1] which relates your issue.
>>>>> Now we will put the response into the fault message if the
>>>>> response is not 200.
>>>>> You can know it when you call the exchange.isfailed().
>>>>>
>>>>> Please check out the latest snapshot and feel free to add your
>>>>> feed back.
>>>>>
>>>>> [1]https://issues.apache.org/activemq/browse/CAMEL-807
>>>>>
>>>>> Willem
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>>
>
> -- 
> View this message in context: http://www.nabble.com/Camel-HTTP-producer-successful-on-404--tp19681729s22882p19691837.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>


Re: Camel HTTP producer successful on 404?

Posted by Willem Jiang <wi...@gmail.com>.
FYI

I created a JIRA[1] and did a quick fix for it.
[1] https://issues.apache.org/activemq/browse/CAMEL-943

Willem

Willem Jiang wrote:
> We can deal with 3xx, 4xx, 5xx with this kind of 
> HttpOperationFailedException.
> Since HttpClient already has the transport exceptions and protocol 
> exceptions, we are doing nothing about these exceptions.They will be 
> thrown directly if the HttpClient throws them.
>
> Willem
> Claus Ibsen wrote:
>> Hi
>>
>> Yeah for 3xx we should get the location that is returned, if any 
>> provided:
>>
>> http://hc.apache.org/httpclient-3.x/redirects.html
>> Header locationHeader = method.getResponseHeader("location");
>>
>> So the end-user can get this new location and retry if he wants to.
>>
>> Yeah maybe we need a special exception where we can store this 
>> location if there is one.
>>
>> Would be fine with a HttpOperationFailedException where we can have 
>> such details stored.
>> - error code
>> - status line
>> - location
>>
>> And it could have a isRedirectError() + hasRedirectLocation () or 
>> whatever so you can do
>>
>> Catch (HttpOperationFailedException e) {
>> If (e.isRedirectError() && e.hasRedirectLocation()) {
>>    // retry with the new location
>>
>> }
>>
>>
>>
>> Med venlig hilsen
>>  
>> Claus Ibsen
>> ......................................
>> Silverbullet
>> Skovsgårdsvænget 21
>> 8362 Hørning
>> Tlf. +45 2962 7576
>> Web: www.silverbullet.dk
>>
>> -----Original Message-----
>> From: Willem Jiang [mailto:willem.jiang@gmail.com] Sent: 27. 
>> september 2008 10:07
>> To: camel-user@activemq.apache.org
>> Subject: Re: Camel HTTP producer successful on 404?
>>
>> I just checked doc of HttpClient[1] , it will not handler redirection 
>> automatically.
>> "Currently HttpClient is unable to automatically handle redirects of 
>> entity enclosing methods such as POST and PUT."
>> Here is a question, if we just throw the exception when we get the 
>> 3xx, how can we extract the location of redirect response from the 
>> exception ?
>> Or we can create a ProtocalExcpection to store the response code and 
>> detail response message.
>>
>> [1] http://hc.apache.org/httpclient-3.x/redirects.html
>>
>> Willem
>> Claus Ibsen wrote:
>>  
>>> Hi
>>>
>>> About: Some of the 3xx errors. Does the http client lib support 
>>> redirection (follow redirection flag or something?). Maybe if there 
>>> was such a flag we should allow this to be configured as well. So 
>>> camel would follow the redirection instruction returned.
>>>
>>>
>>> And it should be documented in the wiki, what we do for the 
>>> different http return codes!
>>>
>>> I don't think we should set any reponse to the FAULT message as we 
>>> are about to @deprecate / alter this for the future. And FAULT is 
>>> seldom used in Camel.
>>>
>>> Otherwise +1
>>>
>>> Med venlig hilsen
>>>  
>>> Claus Ibsen
>>> ......................................
>>> Silverbullet
>>> Skovsgårdsvænget 21
>>> 8362 Hørning
>>> Tlf. +45 2962 7576
>>> Web: www.silverbullet.dk
>>>
>>> -----Original Message-----
>>> From: Willem Jiang [mailto:willem.jiang@gmail.com] Sent: 27. 
>>> september 2008 08:30
>>> To: camel-user@activemq.apache.org
>>> Subject: Re: Camel HTTP producer successful on 404?
>>>
>>> I think we should have a list for the response message code which 
>>> just needs to set the fault message or to throw the exception.
>>> I just check the http status codes means.
>>> 1xx information, 2xx successful, 3xx redirection,  4xx client error, 
>>> 5xx server error.
>>> If the response code is in 1xx , 2xx, 3xx. We just put the message 
>>> into exchange out.
>>> If the response code is between 4xx and 5xx. We could throw the 
>>> exception from the http component to trigger the error handler.
>>>
>>> any thought?
>>>
>>> Willem
>>>
>>>
>>>  
>>> 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
>>>>
>>>>
>>>> Hadrian Zbarcea wrote:
>>>>            
>>>>> Hi,
>>>>>
>>>>> To add to Willem's comment, there is no point in retrying for 404 
>>>>> for  example, but it makes sense to retry for codes like 500.  
>>>>> That means  that we have to enhance the camel-http component to 
>>>>> create 2 classes  of errors and apply the error handle for some, 
>>>>> but not for others.   This is depended on the cleanup in CAMEL-316 
>>>>> that will only be fully  resolved in the next release, and only 
>>>>> partially (we hope) in 1.5.
>>>>>
>>>>> Thanks for riding the camel,
>>>>> Hadrian
>>>>>
>>>>>
>>>>> On Sep 26, 2008, at 4:00 AM, Willem Jiang wrote:
>>>>>
>>>>>                  
>>>>>> Hi ,
>>>>>>
>>>>>> Current HTTP producer will not retry if the response is 401/404/500.
>>>>>> It just put the response back in the fault message body and it 
>>>>>> will  not trigger the default error handler[1] for retring.
>>>>>>
>>>>>> Your application code should call exchang.isFailed() for 
>>>>>> checking  the fault response.
>>>>>>
>>>>>> For the Camel 1.5 , we are planing to cut a RC next week. I 
>>>>>> don't  think camel-http 1.5-SNAPSHOT can work with camel-core 
>>>>>> 1.4, since  they are some change between the core and http 
>>>>>> component in Camel 1.5.
>>>>>> We are publishing the snapshot every day here[2], please take a 
>>>>>> try :)
>>>>>>
>>>>>> [1] http://activemq.apache.org/camel/error-handler.html
>>>>>> [2] http://people.apache.org/repo/m2-snapshot-repository
>>>>>>
>>>>>> Willem
>>>>>>
>>>>>> harinair wrote:
>>>>>>                        
>>>>>>> Willem:
>>>>>>>
>>>>>>> Thanks a lot for the quick reply. So you mean to say that the 
>>>>>>> latest
>>>>>>> SNAPSHOT will mark response != 200 as failed - right? I guess, 
>>>>>>> that  also
>>>>>>> means there will be retries by HTTP producer for 500 / 401/ 404 
>>>>>>> etc.
>>>>>>>
>>>>>>> If that is the case then it is great. When is the 1.5 release  
>>>>>>> planned? I am
>>>>>>> planning to go live this week for a small project and I 
>>>>>>> uncovered  this bug
>>>>>>> on a test. Is 1.5 fairly stable? Or is it recommended that I 
>>>>>>> use  just the
>>>>>>> camel-http component from the 1.5-SNAPSHOT?
>>>>>>>
>>>>>>> Regards,
>>>>>>> Hari Gangadharan
>>>>>>>
>>>>>>>
>>>>>>> willem.jiang wrote:
>>>>>>>
>>>>>>>                              
>>>>>>>> I just did a fixe on CAMEL-807[1] which relates your issue.
>>>>>>>> Now we will put the response into the fault message if the  
>>>>>>>> response is not 200.
>>>>>>>> You can know it when you call the exchange.isfailed().
>>>>>>>>
>>>>>>>> Please check out the latest snapshot and feel free to add your  
>>>>>>>> feed back.
>>>>>>>>
>>>>>>>> [1]https://issues.apache.org/activemq/browse/CAMEL-807
>>>>>>>>
>>>>>>>> Willem
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>                                     
>>>>>>>                               
>>>>>                   
>>>>             
>>>       
>>
>>
>>   
>
>


Re: Camel HTTP producer successful on 404?

Posted by Willem Jiang <wi...@gmail.com>.
We can deal with 3xx, 4xx, 5xx with this kind of 
HttpOperationFailedException.
Since HttpClient already has the transport exceptions and protocol 
exceptions, we are doing nothing about these exceptions.They will be 
thrown directly if the HttpClient throws them.

Willem
Claus Ibsen wrote:
> Hi
>
> Yeah for 3xx we should get the location that is returned, if any provided:
>
> http://hc.apache.org/httpclient-3.x/redirects.html
> Header locationHeader = method.getResponseHeader("location");
>
> So the end-user can get this new location and retry if he wants to.
>
> Yeah maybe we need a special exception where we can store this location if there is one.
>
> Would be fine with a HttpOperationFailedException where we can have such details stored.
> - error code
> - status line
> - location
>
> And it could have a isRedirectError() + hasRedirectLocation () or whatever so you can do
>
> Catch (HttpOperationFailedException e) {
> If (e.isRedirectError() && e.hasRedirectLocation()) {
>    // retry with the new location
>
> }
>
>
>
> Med venlig hilsen
>  
> Claus Ibsen
> ......................................
> Silverbullet
> Skovsgårdsvænget 21
> 8362 Hørning
> Tlf. +45 2962 7576
> Web: www.silverbullet.dk
>
> -----Original Message-----
> From: Willem Jiang [mailto:willem.jiang@gmail.com] 
> Sent: 27. september 2008 10:07
> To: camel-user@activemq.apache.org
> Subject: Re: Camel HTTP producer successful on 404?
>
> I just checked doc of HttpClient[1] , it will not handler redirection 
> automatically.
> "Currently HttpClient is unable to automatically handle redirects of 
> entity enclosing methods such as POST and PUT."
> Here is a question, if we just throw the exception when we get the 3xx, 
> how can we extract the location of redirect response from the exception ?
> Or we can create a ProtocalExcpection to store the response code and 
> detail response message.
>
> [1] http://hc.apache.org/httpclient-3.x/redirects.html
>
> Willem
> Claus Ibsen wrote:
>   
>> Hi
>>
>> About: Some of the 3xx errors. Does the http client lib support redirection (follow redirection flag or something?). Maybe if there was such a flag we should allow this to be configured as well. So camel would follow the redirection instruction returned.
>>
>>
>> And it should be documented in the wiki, what we do for the different http return codes!
>>
>> I don't think we should set any reponse to the FAULT message as we are about to @deprecate / alter this for the future. And FAULT is seldom used in Camel.
>>
>> Otherwise +1
>>
>> Med venlig hilsen
>>  
>> Claus Ibsen
>> ......................................
>> Silverbullet
>> Skovsgårdsvænget 21
>> 8362 Hørning
>> Tlf. +45 2962 7576
>> Web: www.silverbullet.dk
>>
>> -----Original Message-----
>> From: Willem Jiang [mailto:willem.jiang@gmail.com] 
>> Sent: 27. september 2008 08:30
>> To: camel-user@activemq.apache.org
>> Subject: Re: Camel HTTP producer successful on 404?
>>
>> I think we should have a list for the response message code which just 
>> needs to set the fault message or to throw the exception.
>> I just check the http status codes means.
>> 1xx information, 2xx successful, 3xx redirection,  4xx client error, 5xx 
>> server error.
>> If the response code is in 1xx , 2xx, 3xx. We just put the message into 
>> exchange out.
>> If the response code is between 4xx and 5xx. We could throw the 
>> exception from the http component to trigger the error handler.
>>
>> any thought?
>>
>> Willem
>>
>>
>>  
>> 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
>>>
>>>
>>> Hadrian Zbarcea wrote:
>>>   
>>>     
>>>       
>>>> Hi,
>>>>
>>>> To add to Willem's comment, there is no point in retrying for 404 for  
>>>> example, but it makes sense to retry for codes like 500.  That means  
>>>> that we have to enhance the camel-http component to create 2 classes  
>>>> of errors and apply the error handle for some, but not for others.   
>>>> This is depended on the cleanup in CAMEL-316 that will only be fully  
>>>> resolved in the next release, and only partially (we hope) in 1.5.
>>>>
>>>> Thanks for riding the camel,
>>>> Hadrian
>>>>
>>>>
>>>> On Sep 26, 2008, at 4:00 AM, Willem Jiang wrote:
>>>>
>>>>     
>>>>       
>>>>         
>>>>> Hi ,
>>>>>
>>>>> Current HTTP producer will not retry if the response is 401/404/500.
>>>>> It just put the response back in the fault message body and it will  
>>>>> not trigger the default error handler[1] for retring.
>>>>>
>>>>> Your application code should call exchang.isFailed() for checking  
>>>>> the fault response.
>>>>>
>>>>> For the Camel 1.5 , we are planing to cut a RC next week. I don't  
>>>>> think camel-http 1.5-SNAPSHOT can work with camel-core 1.4, since  
>>>>> they are some change between the core and http component in Camel 1.5.
>>>>> We are publishing the snapshot every day here[2], please take a try :)
>>>>>
>>>>> [1] http://activemq.apache.org/camel/error-handler.html
>>>>> [2] http://people.apache.org/repo/m2-snapshot-repository
>>>>>
>>>>> Willem
>>>>>
>>>>> harinair wrote:
>>>>>       
>>>>>         
>>>>>           
>>>>>> Willem:
>>>>>>
>>>>>> Thanks a lot for the quick reply. So you mean to say that the latest
>>>>>> SNAPSHOT will mark response != 200 as failed - right? I guess, that  
>>>>>> also
>>>>>> means there will be retries by HTTP producer for 500 / 401/ 404 etc.
>>>>>>
>>>>>> If that is the case then it is great. When is the 1.5 release  
>>>>>> planned? I am
>>>>>> planning to go live this week for a small project and I uncovered  
>>>>>> this bug
>>>>>> on a test. Is 1.5 fairly stable? Or is it recommended that I use  
>>>>>> just the
>>>>>> camel-http component from the 1.5-SNAPSHOT?
>>>>>>
>>>>>> Regards,
>>>>>> Hari Gangadharan
>>>>>>
>>>>>>
>>>>>> willem.jiang wrote:
>>>>>>
>>>>>>         
>>>>>>           
>>>>>>             
>>>>>>> I just did a fixe on CAMEL-807[1] which relates your issue.
>>>>>>> Now we will put the response into the fault message if the  
>>>>>>> response is not 200.
>>>>>>> You can know it when you call the exchange.isfailed().
>>>>>>>
>>>>>>> Please check out the latest snapshot and feel free to add your  
>>>>>>> feed back.
>>>>>>>
>>>>>>> [1]https://issues.apache.org/activemq/browse/CAMEL-807
>>>>>>>
>>>>>>> Willem
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>           
>>>>>>>             
>>>>>>>               
>>>>>>         
>>>>>>           
>>>>>>             
>>>>     
>>>>       
>>>>         
>>>   
>>>     
>>>       
>>   
>>     
>
>
>   


RE: Camel HTTP producer successful on 404?

Posted by Claus Ibsen <ci...@silverbullet.dk>.
Hi

Yeah for 3xx we should get the location that is returned, if any provided:

http://hc.apache.org/httpclient-3.x/redirects.html
Header locationHeader = method.getResponseHeader("location");

So the end-user can get this new location and retry if he wants to.

Yeah maybe we need a special exception where we can store this location if there is one.

Would be fine with a HttpOperationFailedException where we can have such details stored.
- error code
- status line
- location

And it could have a isRedirectError() + hasRedirectLocation () or whatever so you can do

Catch (HttpOperationFailedException e) {
If (e.isRedirectError() && e.hasRedirectLocation()) {
   // retry with the new location

}



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

-----Original Message-----
From: Willem Jiang [mailto:willem.jiang@gmail.com] 
Sent: 27. september 2008 10:07
To: camel-user@activemq.apache.org
Subject: Re: Camel HTTP producer successful on 404?

I just checked doc of HttpClient[1] , it will not handler redirection 
automatically.
"Currently HttpClient is unable to automatically handle redirects of 
entity enclosing methods such as POST and PUT."
Here is a question, if we just throw the exception when we get the 3xx, 
how can we extract the location of redirect response from the exception ?
Or we can create a ProtocalExcpection to store the response code and 
detail response message.

[1] http://hc.apache.org/httpclient-3.x/redirects.html

Willem
Claus Ibsen wrote:
> Hi
>
> About: Some of the 3xx errors. Does the http client lib support redirection (follow redirection flag or something?). Maybe if there was such a flag we should allow this to be configured as well. So camel would follow the redirection instruction returned.
>
>
> And it should be documented in the wiki, what we do for the different http return codes!
>
> I don't think we should set any reponse to the FAULT message as we are about to @deprecate / alter this for the future. And FAULT is seldom used in Camel.
>
> Otherwise +1
>
> Med venlig hilsen
>  
> Claus Ibsen
> ......................................
> Silverbullet
> Skovsgårdsvænget 21
> 8362 Hørning
> Tlf. +45 2962 7576
> Web: www.silverbullet.dk
>
> -----Original Message-----
> From: Willem Jiang [mailto:willem.jiang@gmail.com] 
> Sent: 27. september 2008 08:30
> To: camel-user@activemq.apache.org
> Subject: Re: Camel HTTP producer successful on 404?
>
> I think we should have a list for the response message code which just 
> needs to set the fault message or to throw the exception.
> I just check the http status codes means.
> 1xx information, 2xx successful, 3xx redirection,  4xx client error, 5xx 
> server error.
> If the response code is in 1xx , 2xx, 3xx. We just put the message into 
> exchange out.
> If the response code is between 4xx and 5xx. We could throw the 
> exception from the http component to trigger the error handler.
>
> any thought?
>
> Willem
>
>
>  
> 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
>>
>>
>> Hadrian Zbarcea wrote:
>>   
>>     
>>> Hi,
>>>
>>> To add to Willem's comment, there is no point in retrying for 404 for  
>>> example, but it makes sense to retry for codes like 500.  That means  
>>> that we have to enhance the camel-http component to create 2 classes  
>>> of errors and apply the error handle for some, but not for others.   
>>> This is depended on the cleanup in CAMEL-316 that will only be fully  
>>> resolved in the next release, and only partially (we hope) in 1.5.
>>>
>>> Thanks for riding the camel,
>>> Hadrian
>>>
>>>
>>> On Sep 26, 2008, at 4:00 AM, Willem Jiang wrote:
>>>
>>>     
>>>       
>>>> Hi ,
>>>>
>>>> Current HTTP producer will not retry if the response is 401/404/500.
>>>> It just put the response back in the fault message body and it will  
>>>> not trigger the default error handler[1] for retring.
>>>>
>>>> Your application code should call exchang.isFailed() for checking  
>>>> the fault response.
>>>>
>>>> For the Camel 1.5 , we are planing to cut a RC next week. I don't  
>>>> think camel-http 1.5-SNAPSHOT can work with camel-core 1.4, since  
>>>> they are some change between the core and http component in Camel 1.5.
>>>> We are publishing the snapshot every day here[2], please take a try :)
>>>>
>>>> [1] http://activemq.apache.org/camel/error-handler.html
>>>> [2] http://people.apache.org/repo/m2-snapshot-repository
>>>>
>>>> Willem
>>>>
>>>> harinair wrote:
>>>>       
>>>>         
>>>>> Willem:
>>>>>
>>>>> Thanks a lot for the quick reply. So you mean to say that the latest
>>>>> SNAPSHOT will mark response != 200 as failed - right? I guess, that  
>>>>> also
>>>>> means there will be retries by HTTP producer for 500 / 401/ 404 etc.
>>>>>
>>>>> If that is the case then it is great. When is the 1.5 release  
>>>>> planned? I am
>>>>> planning to go live this week for a small project and I uncovered  
>>>>> this bug
>>>>> on a test. Is 1.5 fairly stable? Or is it recommended that I use  
>>>>> just the
>>>>> camel-http component from the 1.5-SNAPSHOT?
>>>>>
>>>>> Regards,
>>>>> Hari Gangadharan
>>>>>
>>>>>
>>>>> willem.jiang wrote:
>>>>>
>>>>>         
>>>>>           
>>>>>> I just did a fixe on CAMEL-807[1] which relates your issue.
>>>>>> Now we will put the response into the fault message if the  
>>>>>> response is not 200.
>>>>>> You can know it when you call the exchange.isfailed().
>>>>>>
>>>>>> Please check out the latest snapshot and feel free to add your  
>>>>>> feed back.
>>>>>>
>>>>>> [1]https://issues.apache.org/activemq/browse/CAMEL-807
>>>>>>
>>>>>> Willem
>>>>>>
>>>>>>
>>>>>>
>>>>>>           
>>>>>>             
>>>>>         
>>>>>           
>>>     
>>>       
>>   
>>     
>
>
>   


Re: Camel HTTP producer successful on 404?

Posted by Willem Jiang <wi...@gmail.com>.
I just checked doc of HttpClient[1] , it will not handler redirection 
automatically.
"Currently HttpClient is unable to automatically handle redirects of 
entity enclosing methods such as POST and PUT."
Here is a question, if we just throw the exception when we get the 3xx, 
how can we extract the location of redirect response from the exception ?
Or we can create a ProtocalExcpection to store the response code and 
detail response message.

[1] http://hc.apache.org/httpclient-3.x/redirects.html

Willem
Claus Ibsen wrote:
> Hi
>
> About: Some of the 3xx errors. Does the http client lib support redirection (follow redirection flag or something?). Maybe if there was such a flag we should allow this to be configured as well. So camel would follow the redirection instruction returned.
>
>
> And it should be documented in the wiki, what we do for the different http return codes!
>
> I don't think we should set any reponse to the FAULT message as we are about to @deprecate / alter this for the future. And FAULT is seldom used in Camel.
>
> Otherwise +1
>
> Med venlig hilsen
>  
> Claus Ibsen
> ......................................
> Silverbullet
> Skovsgårdsvænget 21
> 8362 Hørning
> Tlf. +45 2962 7576
> Web: www.silverbullet.dk
>
> -----Original Message-----
> From: Willem Jiang [mailto:willem.jiang@gmail.com] 
> Sent: 27. september 2008 08:30
> To: camel-user@activemq.apache.org
> Subject: Re: Camel HTTP producer successful on 404?
>
> I think we should have a list for the response message code which just 
> needs to set the fault message or to throw the exception.
> I just check the http status codes means.
> 1xx information, 2xx successful, 3xx redirection,  4xx client error, 5xx 
> server error.
> If the response code is in 1xx , 2xx, 3xx. We just put the message into 
> exchange out.
> If the response code is between 4xx and 5xx. We could throw the 
> exception from the http component to trigger the error handler.
>
> any thought?
>
> Willem
>
>
>  
> 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
>>
>>
>> Hadrian Zbarcea wrote:
>>   
>>     
>>> Hi,
>>>
>>> To add to Willem's comment, there is no point in retrying for 404 for  
>>> example, but it makes sense to retry for codes like 500.  That means  
>>> that we have to enhance the camel-http component to create 2 classes  
>>> of errors and apply the error handle for some, but not for others.   
>>> This is depended on the cleanup in CAMEL-316 that will only be fully  
>>> resolved in the next release, and only partially (we hope) in 1.5.
>>>
>>> Thanks for riding the camel,
>>> Hadrian
>>>
>>>
>>> On Sep 26, 2008, at 4:00 AM, Willem Jiang wrote:
>>>
>>>     
>>>       
>>>> Hi ,
>>>>
>>>> Current HTTP producer will not retry if the response is 401/404/500.
>>>> It just put the response back in the fault message body and it will  
>>>> not trigger the default error handler[1] for retring.
>>>>
>>>> Your application code should call exchang.isFailed() for checking  
>>>> the fault response.
>>>>
>>>> For the Camel 1.5 , we are planing to cut a RC next week. I don't  
>>>> think camel-http 1.5-SNAPSHOT can work with camel-core 1.4, since  
>>>> they are some change between the core and http component in Camel 1.5.
>>>> We are publishing the snapshot every day here[2], please take a try :)
>>>>
>>>> [1] http://activemq.apache.org/camel/error-handler.html
>>>> [2] http://people.apache.org/repo/m2-snapshot-repository
>>>>
>>>> Willem
>>>>
>>>> harinair wrote:
>>>>       
>>>>         
>>>>> Willem:
>>>>>
>>>>> Thanks a lot for the quick reply. So you mean to say that the latest
>>>>> SNAPSHOT will mark response != 200 as failed - right? I guess, that  
>>>>> also
>>>>> means there will be retries by HTTP producer for 500 / 401/ 404 etc.
>>>>>
>>>>> If that is the case then it is great. When is the 1.5 release  
>>>>> planned? I am
>>>>> planning to go live this week for a small project and I uncovered  
>>>>> this bug
>>>>> on a test. Is 1.5 fairly stable? Or is it recommended that I use  
>>>>> just the
>>>>> camel-http component from the 1.5-SNAPSHOT?
>>>>>
>>>>> Regards,
>>>>> Hari Gangadharan
>>>>>
>>>>>
>>>>> willem.jiang wrote:
>>>>>
>>>>>         
>>>>>           
>>>>>> I just did a fixe on CAMEL-807[1] which relates your issue.
>>>>>> Now we will put the response into the fault message if the  
>>>>>> response is not 200.
>>>>>> You can know it when you call the exchange.isfailed().
>>>>>>
>>>>>> Please check out the latest snapshot and feel free to add your  
>>>>>> feed back.
>>>>>>
>>>>>> [1]https://issues.apache.org/activemq/browse/CAMEL-807
>>>>>>
>>>>>> Willem
>>>>>>
>>>>>>
>>>>>>
>>>>>>           
>>>>>>             
>>>>>         
>>>>>           
>>>     
>>>       
>>   
>>     
>
>
>   


RE: Camel HTTP producer successful on 404?

Posted by Claus Ibsen <ci...@silverbullet.dk>.
Hi

About: Some of the 3xx errors. Does the http client lib support redirection (follow redirection flag or something?). Maybe if there was such a flag we should allow this to be configured as well. So camel would follow the redirection instruction returned.


And it should be documented in the wiki, what we do for the different http return codes!

I don't think we should set any reponse to the FAULT message as we are about to @deprecate / alter this for the future. And FAULT is seldom used in Camel.

Otherwise +1

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

-----Original Message-----
From: Willem Jiang [mailto:willem.jiang@gmail.com] 
Sent: 27. september 2008 08:30
To: camel-user@activemq.apache.org
Subject: Re: Camel HTTP producer successful on 404?

I think we should have a list for the response message code which just 
needs to set the fault message or to throw the exception.
I just check the http status codes means.
1xx information, 2xx successful, 3xx redirection,  4xx client error, 5xx 
server error.
If the response code is in 1xx , 2xx, 3xx. We just put the message into 
exchange out.
If the response code is between 4xx and 5xx. We could throw the 
exception from the http component to trigger the error handler.

any thought?

Willem


 
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
>
>
> Hadrian Zbarcea wrote:
>   
>> Hi,
>>
>> To add to Willem's comment, there is no point in retrying for 404 for  
>> example, but it makes sense to retry for codes like 500.  That means  
>> that we have to enhance the camel-http component to create 2 classes  
>> of errors and apply the error handle for some, but not for others.   
>> This is depended on the cleanup in CAMEL-316 that will only be fully  
>> resolved in the next release, and only partially (we hope) in 1.5.
>>
>> Thanks for riding the camel,
>> Hadrian
>>
>>
>> On Sep 26, 2008, at 4:00 AM, Willem Jiang wrote:
>>
>>     
>>> Hi ,
>>>
>>> Current HTTP producer will not retry if the response is 401/404/500.
>>> It just put the response back in the fault message body and it will  
>>> not trigger the default error handler[1] for retring.
>>>
>>> Your application code should call exchang.isFailed() for checking  
>>> the fault response.
>>>
>>> For the Camel 1.5 , we are planing to cut a RC next week. I don't  
>>> think camel-http 1.5-SNAPSHOT can work with camel-core 1.4, since  
>>> they are some change between the core and http component in Camel 1.5.
>>> We are publishing the snapshot every day here[2], please take a try :)
>>>
>>> [1] http://activemq.apache.org/camel/error-handler.html
>>> [2] http://people.apache.org/repo/m2-snapshot-repository
>>>
>>> Willem
>>>
>>> harinair wrote:
>>>       
>>>> Willem:
>>>>
>>>> Thanks a lot for the quick reply. So you mean to say that the latest
>>>> SNAPSHOT will mark response != 200 as failed - right? I guess, that  
>>>> also
>>>> means there will be retries by HTTP producer for 500 / 401/ 404 etc.
>>>>
>>>> If that is the case then it is great. When is the 1.5 release  
>>>> planned? I am
>>>> planning to go live this week for a small project and I uncovered  
>>>> this bug
>>>> on a test. Is 1.5 fairly stable? Or is it recommended that I use  
>>>> just the
>>>> camel-http component from the 1.5-SNAPSHOT?
>>>>
>>>> Regards,
>>>> Hari Gangadharan
>>>>
>>>>
>>>> willem.jiang wrote:
>>>>
>>>>         
>>>>> I just did a fixe on CAMEL-807[1] which relates your issue.
>>>>> Now we will put the response into the fault message if the  
>>>>> response is not 200.
>>>>> You can know it when you call the exchange.isfailed().
>>>>>
>>>>> Please check out the latest snapshot and feel free to add your  
>>>>> feed back.
>>>>>
>>>>> [1]https://issues.apache.org/activemq/browse/CAMEL-807
>>>>>
>>>>> Willem
>>>>>
>>>>>
>>>>>
>>>>>           
>>>>         
>>
>>     
>
>   


Re: Camel HTTP producer successful on 404?

Posted by Willem Jiang <wi...@gmail.com>.
I think we should have a list for the response message code which just 
needs to set the fault message or to throw the exception.
I just check the http status codes means.
1xx information, 2xx successful, 3xx redirection,  4xx client error, 5xx 
server error.
If the response code is in 1xx , 2xx, 3xx. We just put the message into 
exchange out.
If the response code is between 4xx and 5xx. We could throw the 
exception from the http component to trigger the error handler.

any thought?

Willem


 
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
>
>
> Hadrian Zbarcea wrote:
>   
>> Hi,
>>
>> To add to Willem's comment, there is no point in retrying for 404 for  
>> example, but it makes sense to retry for codes like 500.  That means  
>> that we have to enhance the camel-http component to create 2 classes  
>> of errors and apply the error handle for some, but not for others.   
>> This is depended on the cleanup in CAMEL-316 that will only be fully  
>> resolved in the next release, and only partially (we hope) in 1.5.
>>
>> Thanks for riding the camel,
>> Hadrian
>>
>>
>> On Sep 26, 2008, at 4:00 AM, Willem Jiang wrote:
>>
>>     
>>> Hi ,
>>>
>>> Current HTTP producer will not retry if the response is 401/404/500.
>>> It just put the response back in the fault message body and it will  
>>> not trigger the default error handler[1] for retring.
>>>
>>> Your application code should call exchang.isFailed() for checking  
>>> the fault response.
>>>
>>> For the Camel 1.5 , we are planing to cut a RC next week. I don't  
>>> think camel-http 1.5-SNAPSHOT can work with camel-core 1.4, since  
>>> they are some change between the core and http component in Camel 1.5.
>>> We are publishing the snapshot every day here[2], please take a try :)
>>>
>>> [1] http://activemq.apache.org/camel/error-handler.html
>>> [2] http://people.apache.org/repo/m2-snapshot-repository
>>>
>>> Willem
>>>
>>> harinair wrote:
>>>       
>>>> Willem:
>>>>
>>>> Thanks a lot for the quick reply. So you mean to say that the latest
>>>> SNAPSHOT will mark response != 200 as failed - right? I guess, that  
>>>> also
>>>> means there will be retries by HTTP producer for 500 / 401/ 404 etc.
>>>>
>>>> If that is the case then it is great. When is the 1.5 release  
>>>> planned? I am
>>>> planning to go live this week for a small project and I uncovered  
>>>> this bug
>>>> on a test. Is 1.5 fairly stable? Or is it recommended that I use  
>>>> just the
>>>> camel-http component from the 1.5-SNAPSHOT?
>>>>
>>>> Regards,
>>>> Hari Gangadharan
>>>>
>>>>
>>>> willem.jiang wrote:
>>>>
>>>>         
>>>>> I just did a fixe on CAMEL-807[1] which relates your issue.
>>>>> Now we will put the response into the fault message if the  
>>>>> response is not 200.
>>>>> You can know it when you call the exchange.isfailed().
>>>>>
>>>>> Please check out the latest snapshot and feel free to add your  
>>>>> feed back.
>>>>>
>>>>> [1]https://issues.apache.org/activemq/browse/CAMEL-807
>>>>>
>>>>> Willem
>>>>>
>>>>>
>>>>>
>>>>>           
>>>>         
>>
>>     
>
>   


Re: Camel HTTP producer successful on 404?

Posted by harinair <ha...@hotmail.com>.
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


Hadrian Zbarcea wrote:
> 
> Hi,
> 
> To add to Willem's comment, there is no point in retrying for 404 for  
> example, but it makes sense to retry for codes like 500.  That means  
> that we have to enhance the camel-http component to create 2 classes  
> of errors and apply the error handle for some, but not for others.   
> This is depended on the cleanup in CAMEL-316 that will only be fully  
> resolved in the next release, and only partially (we hope) in 1.5.
> 
> Thanks for riding the camel,
> Hadrian
> 
> 
> On Sep 26, 2008, at 4:00 AM, Willem Jiang wrote:
> 
>> Hi ,
>>
>> Current HTTP producer will not retry if the response is 401/404/500.
>> It just put the response back in the fault message body and it will  
>> not trigger the default error handler[1] for retring.
>>
>> Your application code should call exchang.isFailed() for checking  
>> the fault response.
>>
>> For the Camel 1.5 , we are planing to cut a RC next week. I don't  
>> think camel-http 1.5-SNAPSHOT can work with camel-core 1.4, since  
>> they are some change between the core and http component in Camel 1.5.
>> We are publishing the snapshot every day here[2], please take a try :)
>>
>> [1] http://activemq.apache.org/camel/error-handler.html
>> [2] http://people.apache.org/repo/m2-snapshot-repository
>>
>> Willem
>>
>> harinair wrote:
>>> Willem:
>>>
>>> Thanks a lot for the quick reply. So you mean to say that the latest
>>> SNAPSHOT will mark response != 200 as failed - right? I guess, that  
>>> also
>>> means there will be retries by HTTP producer for 500 / 401/ 404 etc.
>>>
>>> If that is the case then it is great. When is the 1.5 release  
>>> planned? I am
>>> planning to go live this week for a small project and I uncovered  
>>> this bug
>>> on a test. Is 1.5 fairly stable? Or is it recommended that I use  
>>> just the
>>> camel-http component from the 1.5-SNAPSHOT?
>>>
>>> Regards,
>>> Hari Gangadharan
>>>
>>>
>>> willem.jiang wrote:
>>>
>>>> I just did a fixe on CAMEL-807[1] which relates your issue.
>>>> Now we will put the response into the fault message if the  
>>>> response is not 200.
>>>> You can know it when you call the exchange.isfailed().
>>>>
>>>> Please check out the latest snapshot and feel free to add your  
>>>> feed back.
>>>>
>>>> [1]https://issues.apache.org/activemq/browse/CAMEL-807
>>>>
>>>> Willem
>>>>
>>>>
>>>>
>>>
>>>
>>
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Camel-HTTP-producer-successful-on-404--tp19681729s22882p19691837.html
Sent from the Camel - Users mailing list archive at Nabble.com.


Re: Camel HTTP producer successful on 404?

Posted by Hadrian Zbarcea <hz...@gmail.com>.
Hi,

To add to Willem's comment, there is no point in retrying for 404 for  
example, but it makes sense to retry for codes like 500.  That means  
that we have to enhance the camel-http component to create 2 classes  
of errors and apply the error handle for some, but not for others.   
This is depended on the cleanup in CAMEL-316 that will only be fully  
resolved in the next release, and only partially (we hope) in 1.5.

Thanks for riding the camel,
Hadrian


On Sep 26, 2008, at 4:00 AM, Willem Jiang wrote:

> Hi ,
>
> Current HTTP producer will not retry if the response is 401/404/500.
> It just put the response back in the fault message body and it will  
> not trigger the default error handler[1] for retring.
>
> Your application code should call exchang.isFailed() for checking  
> the fault response.
>
> For the Camel 1.5 , we are planing to cut a RC next week. I don't  
> think camel-http 1.5-SNAPSHOT can work with camel-core 1.4, since  
> they are some change between the core and http component in Camel 1.5.
> We are publishing the snapshot every day here[2], please take a try :)
>
> [1] http://activemq.apache.org/camel/error-handler.html
> [2] http://people.apache.org/repo/m2-snapshot-repository
>
> Willem
>
> harinair wrote:
>> Willem:
>>
>> Thanks a lot for the quick reply. So you mean to say that the latest
>> SNAPSHOT will mark response != 200 as failed - right? I guess, that  
>> also
>> means there will be retries by HTTP producer for 500 / 401/ 404 etc.
>>
>> If that is the case then it is great. When is the 1.5 release  
>> planned? I am
>> planning to go live this week for a small project and I uncovered  
>> this bug
>> on a test. Is 1.5 fairly stable? Or is it recommended that I use  
>> just the
>> camel-http component from the 1.5-SNAPSHOT?
>>
>> Regards,
>> Hari Gangadharan
>>
>>
>> willem.jiang wrote:
>>
>>> I just did a fixe on CAMEL-807[1] which relates your issue.
>>> Now we will put the response into the fault message if the  
>>> response is not 200.
>>> You can know it when you call the exchange.isfailed().
>>>
>>> Please check out the latest snapshot and feel free to add your  
>>> feed back.
>>>
>>> [1]https://issues.apache.org/activemq/browse/CAMEL-807
>>>
>>> Willem
>>>
>>>
>>>
>>
>>
>


Re: Camel HTTP producer successful on 404?

Posted by Willem Jiang <wi...@gmail.com>.
Hi ,

Current HTTP producer will not retry if the response is 401/404/500.
It just put the response back in the fault message body and it will not 
trigger the default error handler[1] for retring.

Your application code should call exchang.isFailed() for checking the 
fault response.

For the Camel 1.5 , we are planing to cut a RC next week. I don't think 
camel-http 1.5-SNAPSHOT can work with camel-core 1.4, since they are 
some change between the core and http component in Camel 1.5.
We are publishing the snapshot every day here[2], please take a try :)

[1] http://activemq.apache.org/camel/error-handler.html
[2] http://people.apache.org/repo/m2-snapshot-repository

Willem

harinair wrote:
> Willem:
>
> Thanks a lot for the quick reply. So you mean to say that the latest
> SNAPSHOT will mark response != 200 as failed - right? I guess, that also
> means there will be retries by HTTP producer for 500 / 401/ 404 etc.
>
> If that is the case then it is great. When is the 1.5 release planned? I am
> planning to go live this week for a small project and I uncovered this bug
> on a test. Is 1.5 fairly stable? Or is it recommended that I use just the
> camel-http component from the 1.5-SNAPSHOT?
>
> Regards,
> Hari Gangadharan
>
>
> willem.jiang wrote:
>   
>> I just did a fixe on CAMEL-807[1] which relates your issue.
>> Now we will put the response into the fault message if the response is 
>> not 200.
>> You can know it when you call the exchange.isfailed().
>>
>> Please check out the latest snapshot and feel free to add your feed back.
>>
>> [1]https://issues.apache.org/activemq/browse/CAMEL-807
>>
>> Willem
>>
>>
>>     
>
>   


Re: Camel HTTP producer successful on 404?

Posted by harinair <ha...@hotmail.com>.
Willem:

Thanks a lot for the quick reply. So you mean to say that the latest
SNAPSHOT will mark response != 200 as failed - right? I guess, that also
means there will be retries by HTTP producer for 500 / 401/ 404 etc.

If that is the case then it is great. When is the 1.5 release planned? I am
planning to go live this week for a small project and I uncovered this bug
on a test. Is 1.5 fairly stable? Or is it recommended that I use just the
camel-http component from the 1.5-SNAPSHOT?

Regards,
Hari Gangadharan


willem.jiang wrote:
> 
> I just did a fixe on CAMEL-807[1] which relates your issue.
> Now we will put the response into the fault message if the response is 
> not 200.
> You can know it when you call the exchange.isfailed().
> 
> Please check out the latest snapshot and feel free to add your feed back.
> 
> [1]https://issues.apache.org/activemq/browse/CAMEL-807
> 
> Willem
> 
> 

-- 
View this message in context: http://www.nabble.com/Camel-HTTP-producer-successful-on-404--tp19681729s22882p19683607.html
Sent from the Camel - Users mailing list archive at Nabble.com.


Re: Camel HTTP producer successful on 404?

Posted by Willem Jiang <wi...@gmail.com>.
I just did a fixe on CAMEL-807[1] which relates your issue.
Now we will put the response into the fault message if the response is 
not 200.
You can know it when you call the exchange.isfailed().

Please check out the latest snapshot and feel free to add your feed back.

[1]https://issues.apache.org/activemq/browse/CAMEL-807

Willem

harinair wrote:
> Hi All:
>
> When I was testing with Camel, I noticed that the HTTP producer sends
> messages to HTTP call back services well but on a 404 or 401 it does not do
> retries? Is that the same case for 500 "Server error" too? Is there any way
> I can modify this so that it will retry again for all response code other
> than 200 OK? In other words any response other than 200 should be an error.
>
> All replies will be greatly appreciated.
>
> Regards,
> Hari Gangadharan
>