[
https://issues.apache.org/jira/browse/JENA-1296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15891990#comment-15891990
]
Vilnis Termanis (Iotic Labs) commented on JENA-1296:
----------------------------------------------------
I've tested against
[apache-jena-fuseki-2.6.0-20170228.233930-10.tar.gz|https://repository.apache.org/content/repositories/snapshots/org/apache/jena/apache-jena-fuseki/2.6.0-SNAPSHOT/apache-jena-fuseki-2.6.0-20170228.233930-10.tar.gz]
and cannot reproduce the lockup.
However, after re-running the original (non-generic) test, I've discovered a
lucene text search related issue. I realise this might be unrelated, but due it
mentioning transactions I thought I'd detail it here before raising a new issue
just in case. Also I cannot reproduce this in v2.3.1 (though I see {{Open
iterator}} warnings every now and again and a 503 timeout) and in the newer
releases the lockup occurs first, so I only see it (the lucene related issue)
in the 2.6.0 snapshot. To summarise (the new behaviour):
- Same 1k.ttl dataset as before
- TDB with lucene text index enabled (will attach)
- Some of the delete+insert queries result in {{500:
java.lang.IllegalStateException: prepareCommit was already called with no
corresponding call to commit}} (will attach logs)
- Reproducible only on 2.6.6 snapshot
> 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)
> Assignee: Andy Seaborne
> Priority: Critical
> Fix For: Jena 3.3.0
>
> Attachments: fuseki_lockup.tgz, lockup_select.sparql,
> lockup_update.sparql, 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)
