You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jena.apache.org by Steve Vestal <st...@adventiumlabs.com> on 2021/10/28 12:26:31 UTC
Suggestions for OWL_MEM_MICRO_RULE_INF
ConcurrentModificationException?
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(LPTopG
oalIterator.java:248)
at org.apache.jena.reasoner.rulesys.impl.LPTopGoalIterator.hasNext(LPTopGo
alIterator.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$TripleMap
per.hasNextBinding(QueryIterTriplePattern.java:143)
at org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryI
teratorBase.java:114)
at org.apache.jena.sparql.engine.iterator.QueryIterRepeatApply.hasNextBind
ing(QueryIterRepeatApply.java:74)
at org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryI
teratorBase.java:114)
at org.apache.jena.sparql.engine.iterator.QueryIterBlockTriplesStar.hasNex
tBinding(QueryIterBlockTriplesStar.java:54)
at org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryI
teratorBase.java:114)
at org.apache.jena.sparql.engine.iterator.QueryIterRepeatApply.makeNextSta
ge(QueryIterRepeatApply.java:101)
at org.apache.jena.sparql.engine.iterator.QueryIterRepeatApply.hasNextBind
ing(QueryIterRepeatApply.java:65)
at org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryI
teratorBase.java:114)
at org.apache.jena.sparql.engine.iterator.QueryIterConvert.hasNextBinding(
QueryIterConvert.java:58)
at org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryI
teratorBase.java:114)
at org.apache.jena.sparql.engine.iterator.QueryIteratorWrapper.hasNextBind
ing(QueryIteratorWrapper.java:38)
at org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryI
teratorBase.java:114)
at org.apache.jena.sparql.engine.iterator.QueryIteratorWrapper.hasNextBind
ing(QueryIteratorWrapper.java:38)
at org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryI
teratorBase.java:114)
at
org.apache.jena.sparql.engine.ResultSetStream.hasNext(ResultSetStream.java:74)
at org.apache.jena.sparql.engine.ResultSetCheckCondition.hasNext(ResultSet
CheckCondition.java:55)
at com.adventiumlabs.fhowl.core.reasoner.StructuredClass.findReifiedStruct
ure(StructuredClass.java:1231)
Re: Suggestions for OWL_MEM_MICRO_RULE_INF
ConcurrentModificationException?
Posted by Steve Vestal <st...@adventiumlabs.com>.
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(L
>>>> PTopGoalIterator.java:222)
>>>> at org.apache.jena.util.iterator.WrappedIterator.hasNext(WrappedIter
>>>> ator.java:90)
>>>> at org.apache.jena.util.iterator.WrappedIterator.hasNext(WrappedIter
>>>> ator.java:90)
>>>> at org.apache.jena.util.iterator.FilterIterator.hasNext(FilterIterat
>>>> or.java:55)
>>>> at org.apache.jena.util.iterator.WrappedIterator.hasNext(WrappedIter
>>>> ator.java:90)
>>>> at org.apache.jena.util.iterator.FilterIterator.hasNext(FilterIterat
>>>> or.java:55)
>>>> at org.apache.jena.sparql.engine.iterator.QueryIterTriplePattern$Tri
>>>> pleMapper.hasNextBinding(QueryIterTriplePattern.java:143)
>>>> at org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(
>>>> QueryIteratorBase.java:114)
>>>> at org.apache.jena.sparql.engine.iterator.QueryIterRepeatApply.hasNe
>>>> xtBinding(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.makeN
>>>> extStage(QueryIterRepeatApply.java:101)
>>>> at org.apache.jena.sparql.engine.iterator.QueryIterRepeatApply.hasNe
>>>> xtBinding(QueryIterRepeatApply.java:65)
>>>> at org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(
>>>> QueryIteratorBase.java:114)
>>>> at org.apache.jena.sparql.engine.iterator.QueryIterConvert.hasNextBi
>>>> nding(QueryIterConvert.java:58)
>>>> at org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(
>>>> QueryIteratorBase.java:114)
>>>> at org.apache.jena.sparql.engine.iterator.QueryIteratorWrapper.hasNe
>>>> xtBinding(QueryIteratorWrapper.java:38)
>>>> at org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(
>>>> QueryIteratorBase.java:114)
>>>> at org.apache.jena.sparql.engine.iterator.QueryIteratorWrapper.hasNe
>>>> xtBinding(QueryIteratorWrapper.java:38)
>>>> at org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(
>>>> QueryIteratorBase.java:114)
>>>> at org.apache.jena.sparql.engine.ResultSetStream.hasNext(ResultSetSt
>>>> ream.java:74)
>>>> at org.apache.jena.sparql.engine.ResultSetCheckCondition.hasNext(Res
>>>> ultSetCheckCondition.java:55)
>>>> at com.adventiumlabs.fhowl.core.reasoner.StructuredClass.findReified
>>>> Structure(StructuredClass.java:1231)
>>>>
Re: Suggestions for OWL_MEM_MICRO_RULE_INF
ConcurrentModificationException?
Posted by Dave Reynolds <da...@gmail.com>.
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)
>>>
>>>
Re: Suggestions for OWL_MEM_MICRO_RULE_INF
ConcurrentModificationException?
Posted by Steve Vestal <st...@adventiumlabs.com>.
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. 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.
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(LP
>> TopGoalIterator.java:248)
>> at org.apache.jena.reasoner.rulesys.impl.LPTopGoalIterator.hasNext(LPT
>> opGoalIterator.java:222)
>> at org.apache.jena.util.iterator.WrappedIterator.hasNext(WrappedIterat
>> or.java:90)
>> at org.apache.jena.util.iterator.WrappedIterator.hasNext(WrappedIterat
>> or.java:90)
>> at org.apache.jena.util.iterator.FilterIterator.hasNext(FilterIterator
>> .java:55)
>> at org.apache.jena.util.iterator.WrappedIterator.hasNext(WrappedIterat
>> or.java:90)
>> at org.apache.jena.util.iterator.FilterIterator.hasNext(FilterIterator
>> .java:55)
>> at org.apache.jena.sparql.engine.iterator.QueryIterTriplePattern$Tripl
>> eMapper.hasNextBinding(QueryIterTriplePattern.java:143)
>> at org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(Qu
>> eryIteratorBase.java:114)
>> at org.apache.jena.sparql.engine.iterator.QueryIterRepeatApply.hasNext
>> Binding(QueryIterRepeatApply.java:74)
>> at org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(Qu
>> eryIteratorBase.java:114)
>> at org.apache.jena.sparql.engine.iterator.QueryIterBlockTriplesStar.ha
>> sNextBinding(QueryIterBlockTriplesStar.java:54)
>> at org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(Qu
>> eryIteratorBase.java:114)
>> at org.apache.jena.sparql.engine.iterator.QueryIterRepeatApply.makeNex
>> tStage(QueryIterRepeatApply.java:101)
>> at org.apache.jena.sparql.engine.iterator.QueryIterRepeatApply.hasNext
>> Binding(QueryIterRepeatApply.java:65)
>> at org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(Qu
>> eryIteratorBase.java:114)
>> at org.apache.jena.sparql.engine.iterator.QueryIterConvert.hasNextBind
>> ing(QueryIterConvert.java:58)
>> at org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(Qu
>> eryIteratorBase.java:114)
>> at org.apache.jena.sparql.engine.iterator.QueryIteratorWrapper.hasNext
>> Binding(QueryIteratorWrapper.java:38)
>> at org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(Qu
>> eryIteratorBase.java:114)
>> at org.apache.jena.sparql.engine.iterator.QueryIteratorWrapper.hasNext
>> Binding(QueryIteratorWrapper.java:38)
>> at org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(Qu
>> eryIteratorBase.java:114)
>> at org.apache.jena.sparql.engine.ResultSetStream.hasNext(ResultSetStre
>> am.java:74)
>> at org.apache.jena.sparql.engine.ResultSetCheckCondition.hasNext(Resul
>> tSetCheckCondition.java:55)
>> at com.adventiumlabs.fhowl.core.reasoner.StructuredClass.findReifiedSt
>> ructure(StructuredClass.java:1231)
>>
Re: Suggestions for OWL_MEM_MICRO_RULE_INF
ConcurrentModificationException?
Posted by Andy Seaborne <an...@apache.org>.
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)
>
>