[
https://issues.apache.org/jira/browse/JENA-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15950653#comment-15950653
]
Vilnis Termanis (Iotic Labs) commented on JENA-1302:
----------------------------------------------------
>From your description I think we're seeing the same thing.I tracked states for
>fuseki sockets during the script run (see annotated netstat.log attached).
{code}
while true; do date && netstat -np | grep 3030 | awk '{print $6}' | sort | uniq
-c && sleep 2; done
{code}
First of all from my understanding, CLOSE_WAIT indicates that the client
(lockup.py) has closed but the server (fuseki/jetty) hasn't (quoting netstat
man page):
bq. CLOSE_WAIT: The remote end has shut down, waiting for the socket to close.
# Initially TIME_WAITs build up (indicating successful finished requests)
# Once the lockup occurs (CPU usage drops) and after at least one request made
by lockup.py times outs (30s), at least one CLOSE_WAIT can be seen (indicating
that, although the client has finished the request the server has not yet
closed the connection.)
# As expected, TIME_WAITs gradually disappear due to lack of new requests being
completed
# Any further requests made thereafter (e.g. "selection of triples" query
example via UI or running lockup.py again) produce more connections in
CLOSE_WAIT once the client has timed out due to lack of server response (or
when one e.g. closes the browser tab/window).
*Conclusion*: The eventual CLOSE_WAIT state is the symptom of Fuseki (via
Jetty) no longer being able to handle additional requests due there still being
a lock held, preventing any other request from being worked on in parallel.
(I.e. same sort of external behaviour as observed in JENA-1296.)
> Intermittent Lucene prepareCommit exception during heavy read/write load
> ------------------------------------------------------------------------
>
> Key: JENA-1302
> URL: https://issues.apache.org/jira/browse/JENA-1302
> Project: Apache Jena
> Issue Type: Bug
> Components: Fuseki, TDB, Text
> Affects Versions: Jena 3.3.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
> Fix For: Jena 3.3.0
>
> Attachments: prepareCommit_error.tgz, visualvm_thread_dump.log
>
>
> (*Note*: Could not add Fuseki 2.6.0 as affected version although I assume
> this is a TDB/text rather than Fuseki-related issue.)
> *Steps:*
> # Start with plain Fuseki + given configuration (TDB store + lucene text
> indexing)
> # Import 1k.ttl
> # Run lockup.py (same host, mix of multiple parallel updates & single select)
> *Result:*
> Every now and again one of the update queries fails with a 500 server error
> which is logged as:
> {{DatasetGraphText ERROR Exception in prepareCommit: prepareCommit was
> already called with no corresponding call to commit}}
> *Notes:*
> - Not reproducible without fix for JENA-1296 (and discovered during fix
> verification for said issue)
> - Run with
> [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]
> - From cold-start of Fuseki, occurs within 30s of script run
> - Supplied test script required Python 3, {{rdflib>=4.2.2}} &
> {{SPARQLWrapper>=1.8.0}}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
