On 10/06/2025 21:21, Øyvind Gjesdal wrote:
Could using try-with resources, and moving the http client init into
existing try-with blocks), or explicitly closing the clients for tests that
use the java http client be useful for Jena6? Autoclosable and some new
methods were added in java 21, see
https://bugs.openjdk.org/browse/JDK-8304165, so when changing Jena to using
two latest LTS, it could be used, instead of waiting for it to handled
during GC.
I did some initial experiments and updating the tests looks mostly
straightforward, unlike understanding the http client usage within Jena
itself, where there is the cache and reuse of clients and usage and reuse
of the default client.
Interesting find.
The recent changes (one server per test, changed from one server per
test class) has improved things greatly. There are a few test suites
still to migrate.
Most use is with the same HttpClient (HttpEnv.getDftHttpClient) to
localhost, and likely http/2. Server-per-test consumes more TCP
connections (one per IP address) but it has made the test situation better.
It isn't the shared HttPCliet is an authenticator is added. The tests
don't use that except when testing it works but add the authentication
headers to the HTTP request.
What might be worth trying as an experiment is to do a "reset" - i.e.
close, recreate - of the commonly used HttpClient at the start of a test
suite which is a single threaded point in the overall test execution.
(IIRC None of the test suites use vast numbers of HTTP or TCP
resources.) Or even on every call to HttpEnv.getDftHttpClient.
That's much of the effect without a large scale rewrite of tests.
My hunch at the moment is that it is at the TCP level and on heavily
loaded GH action servers. The build certainly takes longer are busy
times of day.
Completing a clean shutdown of a TCP connection in the kernel is
asynchronous. If the host kernel is busy, the TCP clean-up is delayed.
Server-per-test ends the server earlier and this starts releasing
network resources.
But that's speculation.
Currently, two tests seems to be the usual points of unexplained build
failures (sometimes there are external causes like can't contact the
outside world to set up the maven environment).
org.apache.jena.sparql.exec.http.TestGSP.gsp_dft_ct_1()
org.apache.jena.sparql.api.TestQueryExecutionCancel.test_cancel_concurrent_2()
TestQueryExecutionCancel is warning about open iterators when it fails.
TestGSP is still server-per-class (via EnvTest)
Andy
On Sun, Jun 1, 2025 at 9:22 PM Arne Bernhardt <arne.bernha...@gmail.com>
wrote:
+1 for GraphMemValue and renaming GraphMem2* to GraphMem*
Andy Seaborne <a...@apache.org> schrieb am Fr., 30. Mai 2025, 18:34:
Another possible change at Jena6:
Move GraphMem out of the way to GraphMemValue (it is only used to give
value semantics for the Model API for java datatypes :
ModelFactory.createDefaultModel. It has been deprecated for awhile).
Then all the "GraphMem2*" can become "GraphMem*".
Andy
