[
https://issues.apache.org/jira/browse/JENA-399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13583845#comment-13583845
]
Hudson commented on JENA-399:
-----------------------------
Integrated in Jena__Development_Test #514 (See
[https://builds.apache.org/job/Jena__Development_Test/514/])
Fix a race condition that may occur when using InfModel in a multi-threaded
environment, it was previously possible for multiple threads to try and call
prepare() and hit ConcurrentModificationException's.
This fix modifies the code for the underlying InfGraph() to make calls to
prepare() synchronized and to ensure threads always see the current prepared
state. This should resolve JENA-399, the previously failing tests are now
enabled (Revision 1448883)
Refactor and expand the multi-threaded query tests to cover SELECT as well.
Determine that I can indeed reproduce the failures intermittently for JENA-399.
The tests that fail are currently @Ignore'd until a workaround can be made
(Revision 1448875)
Incorporated some multi-threaded query test cases from JENA-399 (Revision
1448869)
Result = SUCCESS
rvesse :
Files :
*
/jena/trunk/jena-arq/src/test/java/com/hp/hpl/jena/sparql/core/TestQueryEngineMultiThreaded.java
* /jena/trunk/jena-core/src/main/java/com/hp/hpl/jena/reasoner/BaseInfGraph.java
*
/jena/trunk/jena-core/src/main/java/com/hp/hpl/jena/reasoner/rulesys/BasicForwardRuleInfGraph.java
*
/jena/trunk/jena-core/src/main/java/com/hp/hpl/jena/reasoner/rulesys/FBRuleInfGraph.java
*
/jena/trunk/jena-core/src/main/java/com/hp/hpl/jena/reasoner/rulesys/LPBackwardRuleInfGraph.java
*
/jena/trunk/jena-core/src/main/java/com/hp/hpl/jena/reasoner/rulesys/RETERuleInfGraph.java
*
/jena/trunk/jena-core/src/main/java/com/hp/hpl/jena/reasoner/transitiveReasoner/TransitiveInfGraph.java
rvesse :
Files :
*
/jena/trunk/jena-arq/src/test/java/com/hp/hpl/jena/sparql/core/TestQueryEngineMultiThreaded.java
rvesse :
Files :
*
/jena/trunk/jena-arq/src/test/java/com/hp/hpl/jena/sparql/core/TestQueryEngineMultiThreaded.java
> Concurrent execution of SPARQL CONSTRUCT statements against the same
> Inference Model leads to a ConcurrentModificationException
> -------------------------------------------------------------------------------------------------------------------------------
>
> Key: JENA-399
> URL: https://issues.apache.org/jira/browse/JENA-399
> Project: Apache Jena
> Issue Type: Bug
> Components: ARQ, Reasoners
> Affects Versions: Jena 2.10.0
> Reporter: Stephen Owens
> Assignee: Rob Vesse
> Labels: InfModel, multi-threading, race-condition
> Attachments: JenaReadLockFailureTest.java
>
>
> Read lock seems to be insufficient for a construct SPARQL query against a
> model in a multi-threaded situation. See the attached test case for details.
> The ConcurrentModificationException is thrown from:
> LPTopGoalIterator.checkClosed
> in com.hp.hpl.jena.reasoner.rulesys.impl.LPTopGoalIterator
> Here is a stack trace that shows a path from QueryExecutionBase.
> execConstruct() to LPBRuleEngine.checkSafeToUpdate():
> LPBRuleEngine.checkSafeToUpdate() line: 223
> LPBRuleEngine.deleteAllRules() line: 155
> RDFSRuleInfGraph(FBRuleInfGraph).prepare() line: 460
> RDFSRuleInfGraph(FBRuleInfGraph).findWithContinuation(TriplePattern, Finder)
> line: 573
> RDFSRuleInfGraph(FBRuleInfGraph).graphBaseFind(Node, Node, Node) line: 605
> RDFSRuleInfGraph(GraphBase).find(Node, Node, Node) line: 287
> QueryIterTriplePattern$TripleMapper.<init>(Binding, Triple, ExecutionContext)
> line: 80
> QueryIterTriplePattern.nextStage(Binding) line: 53
> QueryIterTriplePattern(QueryIterRepeatApply).makeNextStage() line: 115
> QueryIterTriplePattern(QueryIterRepeatApply).hasNextBinding() line: 67
> QueryIterTriplePattern(QueryIteratorBase).hasNext() line: 113
> QueryIterBlockTriples.hasNextBinding() line: 64
> QueryIterBlockTriples(QueryIteratorBase).hasNext() line: 113
> QueryIterOptionalIndex(QueryIterRepeatApply).makeNextStage() line: 108
> QueryIterOptionalIndex(QueryIterRepeatApply).hasNextBinding() line: 67
> QueryIterOptionalIndex(QueryIteratorBase).hasNext() line: 113
> QueryIteratorCheck(QueryIteratorWrapper).hasNextBinding() line: 40
> QueryIteratorCheck(QueryIteratorBase).hasNext() line: 113
> QueryIteratorCloseable(QueryIteratorWrapper).hasNextBinding() line: 40
> QueryIteratorCloseable(QueryIteratorBase).hasNext() line: 113
> Iter$5.hasNext() line: 335
> QueryExecutionBase.execConstruct(Model) line: 225
> QueryExecutionBase.execConstruct() line: 201
> This is a problem because LPBRuleEngine.checkSafeToUpdate() closes all
> LPTopGoalIterator iterators, some of which are in the middle of processing:
> public void checkSafeToUpdate() {
> if (!activeInterpreters.isEmpty()) {
> ArrayList<LPInterpreterContext> toClose = new
> ArrayList<LPInterpreterContext>();
> for (Iterator<LPInterpreter> i = activeInterpreters.iterator();
> i.hasNext(); ) {
> LPInterpreter interpreter = i.next();
> if (interpreter.getContext() instanceof LPTopGoalIterator) {
> toClose.add(interpreter.getContext());
> }
> }
> for (Iterator<LPInterpreterContext> i = toClose.iterator();
> i.hasNext(); ) {
> ((LPTopGoalIterator)i.next()).close();
> }
> }
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
