Thank you Oleg. We¹ll stick with it then since it won¹t do any unexpected
harm. The destination HTTP/s server may actually hold the request for 10+
seconds which is ultimately more costly than simply rebuilding a fresh
connection.
‹
Pete
On 3/29/16, 6:42 AM, "Oleg Kalnichevski" <ol...@apache.org> wrote:
>On Fri, 2016-03-25 at 18:42 +0000, Pete Keyes wrote:
>> Are there any significant downsides to using HttpRequest.abort() to
>>signal that a request should give up as soon as possible? Knowing that
>>this is a blocking I/O not the apache async client. Or, is simply
>>better to let it go on naturally and discard the request¹s response
>>whenever it completes?
>>
>> The basic pattern is
>> HttpRequestBase request = ...
>> Future f = executor.submit(r)
>> try {
>> f.get(ms, TimeUnit.MILLISECONDS);
>> }
>> catch(TimeoutException e) {
>> request.abort(); // <<< ?good or bad?
>> throw e;
>> }
>>
>
>It really depends on the average message size and how expensive it is to
>set up new connections. Generally I would probably not do it for TLS/SSL
>connections.
>
>Oleg
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
>For additional commands, e-mail: httpclient-users-h...@hc.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org
