Yes and No The embedded server mode of operation for Fuseki is dependent on Jetty. But the real core of Fuseki is actually just plain Java Servlets and Filter’s and Fuseki’s own dynamic dispatch code.
FWIW I am also a big fan of JAX-RS but moving to JAX-RS would probably be a much more substantiative rewrite. This would need to be done carefully to support Fuseki’s dynamic configuration model but I think it is possible, not sure it’s in-scope for Jena 5 timeframe though Rob From: Martynas Jusevičius <marty...@atomgraph.com> Date: Thursday, 31 August 2023 at 19:35 To: users@jena.apache.org <users@jena.apache.org> Subject: Re: Mystery memory leak in fuseki Does Fuseki have direct code dependency on Jetty? Or would it be possible to try switching to a different servlet container such as Tomcat? JAX-RS, which I’ve advocated here multiple times, provides such a higher-level abstraction above servlets that would enable easy switching. On Fri, 25 Aug 2023 at 16.18, Dave Reynolds <dave.e.reyno...@gmail.com> wrote: > On 25/08/2023 11:44, Andy Seaborne wrote: > > > > > > On 03/07/2023 14:20, Dave Reynolds wrote: > >> We have a very strange problem with recent fuseki versions when > >> running (in docker containers) on small machines. Suspect a jetty > >> issue but it's not clear. > > > > From the threads here, it does seem to be Jetty related. > > Yes. > > We've followed up on Rob's suggestions for tuning the jetty settings so > we can use a stock fuseki. On 4.9.0 if we switch off direct buffer using > in jetty altogether the problem does seem to go away. The performance > hit we see is small and barely above noise. > > We currently have a soak test of leaving direct buffers on but limiting > max and retained levels, that looks promising but too early to be sure. > > > I haven't managed to reproduce the situation on my machine in any sort > > of predictable way where I can look at what's going on. > > Understood. While we can reproduce some effects in desktop test set ups > the only real test has been to leave configurations running for days at > a time in the real dev setting with all it's monitoring and > instrumentation. Which makes testing any changes very painful, let alone > deeper investigations. > > > For Jena5, there will be a switch to a Jetty to use uses jakarta.* > > packages. That's no more than a rename of imports. The migration > > EE8->EE9 is only repackaging. That's Jetty10->Jetty11. > > > > There is now Jetty12. It is a major re-architecture of Jetty including > > it's network handling for better HTTP/2 and HTTP/3. > > > > If there has been some behaviour of Jetty involved in the memory growth, > > it is quite unlikely to carried over to Jetty12. > > > > Jetty12 is not a simple switch of artifacts for Fuseki. APIs have > > changed but it's a step that going to be needed sometime. > > > > If it does not turn out that Fuseki needs a major re-architecture, I > > think that Jena5 should be based on Jetty12. So far, it looks doable. > > Sound promising. Agreed that jetty12 is enough of a new build it's > unlikely to have the same behaviour. > > We've being testing some of our troublesome queries on 4.9.0 on java 11 > vs java 17 and see a 10-15% performance hit on java 17 (even after we > take control of the GC by forcing both to use the old parallel GC > instead of G1). No idea why, seems wrong! Makes us inclined to stick > with java 11 and thus jena 4.x series as long as we can. > > Dave > >
