On 25 Sep 2013, at 12:21 PM, Oleg Kalnichevski <[email protected]> wrote:

> There are probably two most possibilities here: (1) there is a bug in
> HttpClient and the socket value does not correctly apply (I have tested
> such scenario on a number of occasions, so I do not find it likely), (2)
> the target servers keep on sending data either infinitely or at a very
> slow rate (in both cases the connection never reaches the level of
> inactivity for socket timeout to fire).


No, infinitely is impossible because we truncate after 20M.

                                        public Void handleResponse( 
HttpResponse response ) throws ClientProtocolException, IOException {
                                                FetchData.this.response = 
response;
                                                final HttpEntity entity = 
response.getEntity();

                                                if ( entity == null ) 
LOGGER.warn( "Null entity for URL " + url );
                                                else {
                                                        
wrappedEntity.setEntity( entity );
                                                        truncated = 
wrappedEntity.copyContent( maxResponseBodyLength );
                                                        if ( truncated ) 
httpGet.abort();
                                                }
                                                return null;
                                        }} );

wrappedEntity simply copies maxResponseBodyLength bytes and then exits.

It could be infinitely slow rate, but frankly netstat does not report *any* 
open connection.

Nonetheless, after about four hours, 41 out of 42 connections have exited.

Any suggestion to patch this behaviour? One thing we can do is to track the 
URLs that have caused such stalling connections.

Ciao,

                                        seba


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to