Rdf4j-sesameclientimpl thread occupies 100% of the CPU (without any use)

[tomas-knap]

When using rdf4j remote (so having a client connecting to RDF4j server), we experienced on couple of servers that rdf4j-sesameclientimpl-%d thread occupies 100% of the CPU (even if there is no load, no triples added etc.).

I was investigating further and realized that the issue is because of the way how thread pool for the client is created (see the link to see the particular line of code.

The problem is that you defined the thread pool with 0 core threads, but there is a bug in Java 8 core library (the version of Java used by all our 150+ customers) - https://bugs.openjdk.java.net/browse/JDK-8129861

The workaround (suggested in that bug report) is to set number of core threads to 1. So I changed that line of code to:

Executors.newScheduledThreadPool(1, new ThreadFactory() ...

After that change, I saw that immediately the CPU usage went down from 100% to 1% or so.

We are currently using 2.3.2. Can you please do that single line of code change for us and create a bugfix release 2.3.3?

Thank you! Tomas Knap, Semantic Web Company

[barthanssens]

Also present in newer releases apparently...

Since it's a bug in OpenJDK, perhaps it should be selectable (e.g. by setting a system property), whether or not the number of core threads should be 0 or 1 ?

[barthanssens]

@tomas-knap there's a PR with slightly different code (using a system property), would this be a workable solution for you ?

[abrokenjester]

Apparently, Github does not allow more than one milestone on an issue 👎

@tomas-knap Thanks for reporting this. Let us know if the fix as implemented by @barthanssens is workable for you. We can accomodate doing a 2.3.3 hotfix release for this. This release will only include a fix for this particular issue. We'll likely immediately follow that with a 2.4.4 patch release as well, so that this particular fix will also be available in the latest stable release.

[tomas-knap]

@jeenbroekstra Thank you for the quick response!

Yes, the fix suggested by @barthanssens is OK - it is even better than change it in the code to 1, as the workaround (1 core thread instead of 0) includes one more idle thread, which is probably waste of resources from jdk9+.

So yes, please go ahead with the PR #1272 and please let me know when 2.3.3 hotfix release is ready (please create also the one-jar version with all RDF4j modules).

Thank you!

[barthanssens]

OK, I'll start the backport and release process this evening (CET). If all goes well a full 2.3.3 should be available within a day or two (depending on how smoothly the build farm runs + some manual actions)

[barthanssens]

@tomas-knap 2.3.3 is available for download on the rdf4j.org website

[hmottestad]

Can we close this issue now? Documentation and backporting complete?