You should use the HTTP header "message-id" in each call. The value for that header should be identical for each retry, but it must be unique from all other HTTP messages you sent in the past. Read the AS2 RFC (RFC-4130) about how the "message-id" HTTP header should be formatted ... ignore all the other details about the RFC and just focus on the "message-id" usage.
This will ensure that your customers can sort thru unique HTTP messages versus duplicates caused by errors only on your side of the HTTP transaction. Hope this helps ... ...Pete ________________________________________ From: Oleg Kalnichevski [[email protected]] Sent: Monday, May 30, 2011 03:43 AM To: HttpClient User Discussion Subject: Re: Retrying a HTTP call.. On Mon, 2011-05-30 at 14:25 +0530, Manikandan R wrote: > Oleg, > > Ok, Thanks. > > Any other recommendation/work around to achieve this? > > Please suggest. > > Thanks, > Mani > Making each message include a unique ID of some sort would be my choice. Oleg > On Mon, May 30, 2011 at 1:55 PM, Oleg Kalnichevski <[email protected]> wrote: > > > On Mon, 2011-05-30 at 10:40 +0530, Manikandan R wrote: > > > Hi Everyone, > > > > > > I've started using apache commons httpclient library (version no. 3.1) to > > > make the http calls recently. In production environment, seeing the > > > following exceptions in logs: > > > > > > 1. Broken Pipe > > > 2. Connection Reset > > > 3. Connection Timeout > > > 4. Read Time out > > > etc > > > > > > Whenever these exceptions, we get the complaints from customers not > > > completing the tasks. So, we repeat the work manually. To avoid doing it > > > manually, program should take care of the retries without causing any > > > duplicates. I am not sure when to do the retry. Basically, for what type > > of > > > exceptions, Should I do retry so that it won't end up in duplicates? > > > > > > Please suggest. > > > > > > Thanks, > > > Mani > > > > HTTP is a non-transaction protocol with non-guaranteed delivery of > > messages. You either have to live with HTTP messages being not delivered > > at all in some cases or delivered multiple times. > > > > Oleg > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
