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/10/01 00:41:34 UTC
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 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.