GH-4084: Fix ByteBufferPool sizing in Fuseki's Jetty Server#4088
Open
divyankshah wants to merge 1 commit into
Open
GH-4084: Fix ByteBufferPool sizing in Fuseki's Jetty Server#4088divyankshah wants to merge 1 commit into
divyankshah wants to merge 1 commit into
Conversation
Fuseki builds its Jetty Server with new Server(threadPool), which wires in a default ArrayByteBufferPool capped at 64KB. Fuseki configures a 5MB outputBufferSize, so output buffers exceed the pool's max capacity and are discarded on release instead of reused, causing continuous DirectMemory churn under load. Fixed in JettyServer.jettyServer(...), the shared factory both JettyHttps.java and FusekiServer.java call, so neither file needs changes. Constructs an ArrayByteBufferPool sized to FusekiSystemConstants.jettyOutputBufferSize and passes it into Server(ThreadPool, Scheduler, ByteBufferPool) at construction time, since adding the pool via addBean() afterward has no effect (the default pool is already wired in during construction).
AniRamadoss
reviewed
Jul 24, 2026
| } | ||
| } | ||
|
|
||
| public static Server jettyServer(int minThreads, int maxThreads) { |
There was a problem hiding this comment.
Did we also want to address the other route that Andy mentioned on #4084 (comment) ?
Author
There was a problem hiding this comment.
Hi @AniRamadoss, Thank you for asking - yes, it's covered. FusekiServer.java#L1907 calls
JettyServer.jettyServer(minThreads, maxThreads), the same shared factory I fixed. Since
the pool construction now lives inside that factory, both JettyHttps.java and
FusekiServer.java inherit the fix automatically also neither file needed direct changes,
it is dependent on JettyServer.java.
I confirmed this by tracing both call sites before submitting, also happy to paste the
exact call chain here if it's useful for review.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #4084
Fuseki builds its Jetty
Serverwithnew Server(threadPool), which wires in adefault
ArrayByteBufferPoolcapped at 64KB. Fuseki configures a 5MBoutputBufferSize, so every output buffer exceeds the pool's max capacity and getsdiscarded on release instead of reused, causing continuous DirectMemory churn under
load. Full analysis in #4084.
This fixes it in
JettyServer.jettyServer(...), the shared factory bothJettyHttps.javaandFusekiServer.javacall, so neither file needs changes.Constructs an
ArrayByteBufferPoolsized toFusekiSystemConstants.jettyOutputBufferSizeand passes it intoServer(ThreadPool, Scheduler, ByteBufferPool)at construction time (adding the poolvia
addBean()afterward doesn't work, since the default pool is already wired induring construction).
Added a test asserting the built server's pool max capacity covers the configured
output buffer size. Full
jena-fuseki-mainsuite passes (799/799).