Joan Balagueró wrote:
Thanks Oleg. It seems strange to me because HttpClient3 (sending requests to the same server) never fails. I'll take a look at the code again and I'll comment you something else.
I do not know why the server chokes on packets generated by HttpClient 4, but this is clearly a server side problem. The server should return a non 2xx response if something is not okay, not just drop the connection.
HTTP/1.0 can be a problem or absence of User-Agent header. Whatever. At any rate the server is broken.
Just another question. When I modify a connection or response timeout setting another value (for example, from 5000 to 2000) HttpClient4 applies this new value correctly (as expected, obviously). But not the same with maxConnections. If I set MaxConnections from 100 to 1 using ConnManagerParams.setMaxTotalConnections, then: DefaultHttpClient object --> DefaultParams --> parameters --> http.conn-manager.max-total=1 --> OK! But DefaultHttpClient object --> connManager --> connectionPool --> maxTotalConnections still to 100 --> BAD! And if I send 50 simultaneous request, HttpClient processes all of them even with maxTotalConnections to 1. Is this a bug? Or after "ConnManagerParams.setMaxTotalConnections" I must set the new "param" values to the HttpClient object with "this.objHttp.setParams(set the "params" object with the new value of MaxConnections)"?
This happens because the connection manager does not reset the existing connection pools for established routes. One can see this as a bug or a 'feature' as one can look at it from different perspectives. To me this is an expected behavior. MaxTotalConnections parameter is expected to be set at the start up time and to not mutate afterwards.
Oleg
Thanks, Joan.
--------------------------------------------------------------------- To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
