Luckily, input streams are not involved in my client requests, at least not
for now. But you have a good point here, I'll need to add some logic to
buffer the request entity for such cases in the future. I think the
buffering cost is somewhat less problematic on the client side than on the
server side.
--
Sent from my mobile device.
On Sep 27, 2013, at 4:46 PM, cowwoc <cowwoc_at_bbs.darktech.org> wrote:
Out of curiosity, how did you implement this using ClientFilter? Did
you buffer the request entity every time even if a retry didn't turn out to
be necessary?
I gave up on server-side retries and mandating that clients must retry
on their end. See http://stackoverflow.com/a/17960047/14731 for more
information.
Gili
On 27/09/2013 4:31 PM, Ward Flores wrote:
Hi all,
I have introduced an http request retry mechanism on the client side using
a custom ClientFilter. It works great!
Now, I'd like to introduce a similar mechanism on the server side. However,
filters (nor the new interceptors in 2.x) seem to provide a support to do
that as it is the case with the ClientFilter.
I'm just wondering how do my fellow colleagues attack this problem. Do you
have something in place to retry your http requests on the server side?
Regards,
--
Ward Flores
wflores.qc.ca_at_gmail.com
"Aussi longtemps que j'aurai des ailes, j'irai lą oł mon coeur m'appelle" -
Les Colocs