[JENA-1296] Fuseki SPARQL endpoints become permanently unresponsive after read/write load

• Type: Bug
• Status: Closed
• Priority: Critical
• Resolution: Fixed
• Affects Version/s: Fuseki 2.4.1, Fuseki 2.5.0
• Fix Version/s: Jena 3.3.0
• Component/s: Fuseki, TDB

Environment

CentOS 7.3 inside VM, 2 cores, OpenJDK 1.8.0_121 (64-bit), 1GB JVM heap, Fuseki running as service

• Assignee: Andy Seaborne
• Reporter: Vilnis Termanis (Iotic Labs)
• Created: 24/Feb/17 18:53
• Updated: 10/May/17 15:35
• Resolved: 28/Feb/17 22:56

Description

Steps:

1. Start with plain Fuseki + given configuration (simple TDB store)
2. Import 1k.ttl
3. Run lockup.py (same host, mix of multiple parallel updates & single select)

Result:
After some time Fuseki stops accepting any additional SPARQL queries until it is restarted. (They time out at client end and are left in CLOSE_WAIT state on server). During my testing this happened within ~30s of running the script.

Notes:

• Locks up more quickly if JVM has had cold start (e.g. restart after step 2) but it definitely is not only a startup issue.
• During testing the VM was very rarely I/O limited.
• The "static" web UI elements are accessible, but any SPARQL-querying features (e.g. triple count) do not
• Reproducible as detailed above in v2.4.1 & v2.5.0
• In v2.4.0 and v2.3.1 no lockup seems to occur, but once the script has been running for a while, the SELECT query times out sometimes.

So for now we're limited to using the (now somewhat old) v2.3.1 - it would be nice to be able to upgrade.