> Are you using TDB1? TDB2?
It's not even possible to use TDB1 with 5.1.0, UI offers just in-memory and
TDB2 databases.
- Jaana
> 29.10.2024 19.17 EET Andy Seaborne <a...@apache.org> kirjoitti:
>
>
> On 29/10/2024 13:43, jaa...@kolumbus.fi wrote:
> >> 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.
> >
> > Does it mean that 5.1.0 requires much more meomory ?
>
> In your case, it would seem so. From Jena, from Jetty, generally. Maybe
> some internal caches are bigger - there could be lots of reasons from
> the lifecycle of the memory releasing to man, many small things.
>
> If you care, then bisect on versions to find out.
>
> Are you using TDB1? TDB2?
>
> Andy
>
> > Jaana
> >
> >> 29.10.2024 14.13 EET Andy Seaborne <a...@apache.org> kirjoitti:
> >>
> >>
> >> 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
