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

["Vilnis Termanis (Iotic Labs) (JIRA)" <ji...@apache.org>]

    [ 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)