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.
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?
Thanks,
Joan.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
