On 24/12/14 11:04, Petr Baudis wrote:
Hi!
On Wed, Dec 24, 2014 at 10:01:41AM +0000, Andy Seaborne wrote:
What i think is happening is that if you don't do the close, then
the connection isn't return to the pool and a new one is created
when the next request comes in. Hence lots of connections all the
way through to the server.
Hmm, I don't see reusing of connections even when I do .close(),
though. I'll take look later if I can easily make it reuse connections
with a custom http client class.
Still, I think it'd be worthwhile to time out open connections on the
Fuseki server side after a while. Otherwise, it is e.g. trivial to DDoS
a server open to the internet.
Do you have a test case?
I wrote a quick test and traced connections getting put back in the pool
on the client side in tests of 20K requests.
ManagedClientConnectionImpl does get called to recycle the connection.
But it was a same-machine test (due to where I am ATM). From memory,
freeing client and server side resources isn't completely synchronous
with the local OS and it has been possible to run faster than the OS
frees up connections. It might be better to reduce the HttpClient
configuration.
On the server side this is all inside Jetty. There is a tension between
freeing resources and caching. Maybe the code is asking for cached
connections too quickly.
Andy
