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
