You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by "Andy Seaborne (JIRA)" <ji...@apache.org> on 2017/02/26 15:59:46 UTC
[jira] [Commented] (JENA-1296) Fuseki SPARQL endpoints become
permanently unresponsive after read/write load
[ https://issues.apache.org/jira/browse/JENA-1296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15884795#comment-15884795 ]
Andy Seaborne commented on JENA-1296:
-------------------------------------
Thanks for the report.
JENA-1224 is a possible cause. This was added because of a user report
https://lists.apache.org/thread.html/99b01f1dc7af86e0832279a85da6963985fc9f1f2c36d3c3969aaeb1@%3Cusers.jena.apache.org%3E
but there is a bug in the {{TransactionManager}}.
It looks ike it cause what you're seeing but I can't get lockup.py to run on my machine. The current version of SPARQLWrapper does not work with it (I get python syntax errors, then if I fix that more, different syntax errors). Maybe my Python foo is weak.
Could you provide a self contained version of lockup.py that includes its dependencies please?
> Fuseki SPARQL endpoints become permanently unresponsive after read/write load
> -----------------------------------------------------------------------------
>
> Key: JENA-1296
> URL: https://issues.apache.org/jira/browse/JENA-1296
> Project: Apache Jena
> Issue Type: Bug
> Components: Fuseki, TDB
> Affects Versions: Fuseki 2.4.1, Fuseki 2.5.0
> Environment: CentOS 7.3 inside VM, 2 cores, OpenJDK 1.8.0_121 (64-bit), 1GB JVM heap, Fuseki running as service
> Reporter: Vilnis Termanis (Iotic Labs)
> Priority: Critical
> Attachments: fuseki_lockup.tgz, threaddump-1487963000778.tdump
>
>
> *Steps:*
> # Start with plain Fuseki + given configuration (simple TDB store)
> # Import 1k.ttl
> # 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.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)