To wrap this up, Dave, you are right about a resource being found that was not an OntClass.  Most select rows were as expected, but it did find a solution where the resource had an additional rdf:type that was not an owl:Class.  Problem solved, thanks for the help everyone.

On 11/1/2021 1:27 PM, Dave Reynolds wrote:
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)

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

Reply via email to