On 29/10/2024 11:12, jaa...@kolumbus.fi wrote:
Hi,
1. Check that the client is properly reading the whole of the response
9even if zero bytes) and is actually closing the connection, or
returning it to the connection pool. Check by running "netstat" to see
TCp connections ("-t" on *nix)
With netstat I saw several connections in TIME_WAIT state when running my test.
I think it means that the tcp-connections have been properly closed.
(the test being the large run?)
That's good - the important point is that there are not hundred's of
connections.
I understand that unproperly terminated tcp-connections could lead to error case
"Maximum lock count exceeded", but what could cause jena-fuseki 5.1.0 use much
more memory than 3.14 did with exactly same program code and input in the client side and
same data in the database ?
The gap between 3.14.0 and 5.1.0 is huge. There is also a Jetty change -
Jetty 12 is a fundamentally different architecture in its HTTP handling.
Andy
