On 01/11/2021 17:18, Steve Vestal wrote:
Thanks, this started me down the path to a solution.
For the record, I searched through my code, and I could not find
multiple threads accessing the model. This was occurring during a
SPARQL query of an OntModel. Is it possible ARQ uses threads? Below is
what I tried, which it seems does add triples to the model.
Yes, createClass will add a statement so that the given resource is
indeed a class, in case presumably: "<resource> rdf:type owl:Class.".
So you are adding statements to a model that you are iterating over, the
reasoner will be testing for things like type statements, hence the CME,
no threads needed.
I still got
a ConcurrentModificationException at the second iteration of the
selectResult.hasNext() call, with these transaction statements added.
When I commented-out the createClass (and its subsequent use), the
exception disappeared. I could restructure the code so that the recovery
of the Resource as an OntClass happened outside this loop. I'm not sure
why it didn't recognize that thisClassResource was an OntClass in the
ontoModel, though.
Presumably the resources found by your query aren't (or aren't all)
explicitly declared as instances owl:Class.
Dave
QueryExecution selectExec =
QueryExecutionFactory.create(textSelectQuery, ontoModel);
Dataset selectData = selectExec.getDataset();
selectData.begin(ReadWrite.WRITE);
ResultSet selectResult = selectExec.execSelect();
while (selectResult.hasNext()) {
RDFNode thisClassNode =
selectSolution.get(STRUCTURE_CLASS_VAR);
Resource thisClassResource = thisClassNode.asResource();
//OntClass thisClass = thisClassNode.as(OntClass.class); //
didn't work for me.
OntClass thisClass =
ontoSetModel.createClass(thisClassResource.getURI()); // attempted
workaround for above
selectData.commit()
// other stuff...
}
selectData.end(); // Doesn't get this far
On 10/29/2021 4:00 AM, Andy Seaborne wrote:
Steve,
Is your usage multithreaded? If so, you'll need to make sure that
usage is mutlireaer or single writer.
Using jena transaction mecahnism is best - they work with datasets and
choose the best implementation for the datasets. For ones containing
inference, that's MRSW locking.
Another approach is to not reuse the inf model but to create a new
one. Any operation gets the model to work with from some
AtomicReference<>.
Then outstanding threads finish what they are doing with the old setup
while new requests get the new view. Teh garbage collector wil reclaim
space sometime after all the outstanding old operatiosn have finished.
Andy
On 28/10/2021 13:26, Steve Vestal wrote:
Does anyone have any suggestions on things to try to avoid a
ConcurrentModificationException when using
OWLReasoner.OWL_MEM_MICRO_RULE_INF? Or what the potential
consequences of that are? (The below stack dump only goes back to
where my code made the call, the full one is fairly lengthy and full
of Eclipse stuff as well as mine. This is Jena 3.17.)
I am doing something a bit odd. There is one imported model that
gets reloaded from time-to-time, at the end of which I do an
ontModel.getBaseModel().rebind(). (The overall intent is sort of a
backwards base v schema workflow, where it is a small set of
definitions and axioms applied to the same big base model that get
changed.) I get this exception shortly after doing a reload/rebind,
such as the first one or few queries (as in this stackdump). After
that things seem to work OK. I only get the one exception after a
reload/rebind. I'd still like to (someday) understand what I'm
doing, though.
Openllet/Pellet doesn't do this, but that is overkill and noticeably
slower for many workflows.
There is some punning done in the big base model, but works OK in
many workflows. This is the only case where I have seen anything
other than a few "not supported" warnings.
java.util.ConcurrentModificationException
at
org.apache.jena.reasoner.rulesys.impl.LPTopGoalIterator.checkCME(LPTopGoalIterator.java:248)
at
org.apache.jena.reasoner.rulesys.impl.LPTopGoalIterator.hasNext(LPTopGoalIterator.java:222)
at
org.apache.jena.util.iterator.WrappedIterator.hasNext(WrappedIterator.java:90)
at
org.apache.jena.util.iterator.WrappedIterator.hasNext(WrappedIterator.java:90)
at
org.apache.jena.util.iterator.FilterIterator.hasNext(FilterIterator.java:55)
at
org.apache.jena.util.iterator.WrappedIterator.hasNext(WrappedIterator.java:90)
at
org.apache.jena.util.iterator.FilterIterator.hasNext(FilterIterator.java:55)
at
org.apache.jena.sparql.engine.iterator.QueryIterTriplePattern$TripleMapper.hasNextBinding(QueryIterTriplePattern.java:143)
at
org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114)
at
org.apache.jena.sparql.engine.iterator.QueryIterRepeatApply.hasNextBinding(QueryIterRepeatApply.java:74)
at
org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114)
at
org.apache.jena.sparql.engine.iterator.QueryIterBlockTriplesStar.hasNextBinding(QueryIterBlockTriplesStar.java:54)
at
org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114)
at
org.apache.jena.sparql.engine.iterator.QueryIterRepeatApply.makeNextStage(QueryIterRepeatApply.java:101)
at
org.apache.jena.sparql.engine.iterator.QueryIterRepeatApply.hasNextBinding(QueryIterRepeatApply.java:65)
at
org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114)
at
org.apache.jena.sparql.engine.iterator.QueryIterConvert.hasNextBinding(QueryIterConvert.java:58)
at
org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114)
at
org.apache.jena.sparql.engine.iterator.QueryIteratorWrapper.hasNextBinding(QueryIteratorWrapper.java:38)
at
org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114)
at
org.apache.jena.sparql.engine.iterator.QueryIteratorWrapper.hasNextBinding(QueryIteratorWrapper.java:38)
at
org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114)
at
org.apache.jena.sparql.engine.ResultSetStream.hasNext(ResultSetStream.java:74)
at
org.apache.jena.sparql.engine.ResultSetCheckCondition.hasNext(ResultSetCheckCondition.java:55)
at
com.adventiumlabs.fhowl.core.reasoner.StructuredClass.findReifiedStructure(StructuredClass.java:1231)
