On Thu, 2013-01-31 at 17:33 +0100, [email protected] wrote: > Hello, > > Just one problem about socket timeout. > > My app uses the PoolingConnectionManager intensively (hundreds of > threads getting connections from it simultaneously). The response > (socket) timeout is set to 20 seconds. And this limit is very important, > because the cms collector is specifically configured thinking that all > requests will take, at most, 20 seconds (otherwise the socket timeout > should be triggered and the thread should die). If this does not occur, > I'll have an overflow of objects in the young generation (and survivor > spaces) and, in consequence, a lot of objects (that should be death) > will go to the old generation because they're still alive. > > Well, I understand that socket timeout is not the same than response > timeout. The socket timeout is the maximum amount of seconds allowed > between two packets. > The response timeout is the maximum time that a response received from > a server can take (from the first to the last packet). > > Therefore, a socket timeout of 20 seconds does not guarantee a response > timeout of 20 seconds (in fact, the response timeout will always be > greater than socket tiemout because the server can deliver packets > slowly but always under the 20 seconds). > > Then, the question is: how can I implement a response timeout in > httpclient that guarantees the 20 seconds? I can imagine some ways to > implement it, but maybe using the same httpclient there is a known way > to do it. >
There are presently no way to implement a response deadline (or response timeout) with HttpClient other than using an additional monitoring thread. A proper support for response deadlines would be very difficult with a blocking i/o model and would require a substantial amount of ugly code. It should be easier with a non-blocking i/o, though. > And another question (nothing to see with the above). I'm experimenting > some lock contention in the pool (due to the global lock that is > guarding it in order to calculate correctly the maxconnections). Reading > a previous email, where you said: "What might be a possibility is > creating a more lenient and less prone to lock contention issues > implementation that may under stress occasionally allocate a few more > connections than the max limits.". Is this a feature that you'll > implement in the next version? > I experimented with this idea a while ago (you can find the source code of my experimental connection manager in the mail archive) but did not get any considerable performance improvement compared to the standard connection manager. I do not think I will invest any more time into pursuit of this idea, but could provide assistance to anyone willing to take over the work. Oleg > Thanks, > Joan. > > > > --------------------------------------------------------------------- > 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]
