Thank you Dave (sorry I switched the name before).
I just managed to find where the real problem was. I had a timestamp update
in the base constructor of the enhanced node class implementations (which
doesn't make any sense, now that I think about it).
When the as() method was invoked, a new instance of the class
implementation was created and the update operation performed:
static final public com.hp.hpl.jena.enhanced.Implementation factory = new
com.hp.hpl.jena.enhanced.Implementation() {
public com.hp.hpl.jena.enhanced.EnhNode wrap(com.hp.hpl.jena.graph.Node n,
com.hp.hpl.jena.enhanced.EnhGraph eg) {
if (canWrap(n, eg)) {
*return new pt.ipp.isep.gecad.onto2flow.model.impl.NodeImpl*(n, eg);
} else {
throw new com.hp.hpl.jena.ontology.ConversionException(
"Cannot convert node " + n.toString() + " to Node: it does not have
rdf:type http://gecad.isep.ipp.pt/Onto2Flow#Node or equivalent!");
}
}
public boolean canWrap(com.hp.hpl.jena.graph.Node n,
com.hp.hpl.jena.enhanced.EnhGraph eg) {
return eg.asGraph().contains(n,
com.hp.hpl.jena.vocabulary.RDF.type.asNode(),
pt.ipp.isep.gecad.onto2flow.model.O2F.Node.asNode());
}
};
Thank you for all your help =)
On Thu, Sep 12, 2013 at 7:59 PM, Dave Reynolds <[email protected]>wrote:
> On 12/09/13 14:51, Nuno Luz wrote:
>
>> Hi Andi,
>> As you mentioned, it seems the problem comes from a toString() invocation.
>> After some testing, I noticed that the exception only happens when I
>> invoke
>> the Edge.toString() method inside the iteration.
>> However, no changes seem to be performed there (at least explicitly).
>> After
>> slicing some code I verified that the problem comes from this method,
>> which
>> is invoked inside the Edge.toString():
>>
>> protected <T extends RDFNode> T getResourceProperty(Property p, Class<T>
>> withType) {
>> for (StmtIterator it = listProperties(p); it.hasNext();) {
>> Statement stm = it.next();
>> RDFNode node = stm.getObject();
>> if (node.canAs(withType)) {
>> return node.as(withType);
>> }
>> }
>>
>> return null;
>> }
>>
>> Can it be related to the RDFNode.as()?
>>
>
> Potentially, it depends what the actual value of node and the value of
> "withType" The as() operation basically calls the convertTo operation on
> the node. With the basic RDF types then this won't be side-effecting but
> there are cases where the OntAPI types will add rdf:type statements.
>
> Dave
>
>
>> Thank you!
>>
>>
>>
>> On Thu, Sep 12, 2013 at 8:12 AM, Dave Reynolds <[email protected]
>> >**wrote:
>>
>> On 12/09/13 00:37, Nuno Luz wrote:
>>>
>>> Hi Dave and Andy,
>>>> The underlying graph is plain, created through
>>>> GraphFactory.****createDefaultGraph().
>>>>
>>>>
>>> In that case there must be some modification to the graph happening
>>> somewhere in your code. ConcurrentModificationExceptio****n just means
>>> what
>>>
>>> it says, I'm not aware of another way of causing it apart from some
>>> actual
>>> modification going on while you are iterating.
>>>
>>>
>>> As for the stack trace:
>>>
>>>>
>>>> java.util.****ConcurrentModificationExceptio****n
>>>> at com.hp.hpl.jena.mem.****ArrayBunch$2.hasNext(****
>>>> ArrayBunch.java:129)
>>>> at
>>>> com.hp.hpl.jena.util.iterator.****WrappedIterator.hasNext(**
>>>> WrappedIterator.java:76)
>>>> at
>>>> com.hp.hpl.jena.util.iterator.****FilterIterator.hasNext(**
>>>> FilterIterator.java:55)
>>>> at
>>>> com.hp.hpl.jena.util.iterator.****WrappedIterator.hasNext(**
>>>> WrappedIterator.java:76)
>>>> at
>>>> com.hp.hpl.jena.util.iterator.****NiceIterator$1.hasNext(**
>>>> NiceIterator.java:104)
>>>> at com.hp.hpl.jena.util.iterator.****Map1Iterator.hasNext(**
>>>> Map1Iterator.java:50)
>>>> at
>>>> com.hp.hpl.jena.util.iterator.****WrappedIterator.hasNext(**
>>>> WrappedIterator.java:76)
>>>> at com.hp.hpl.jena.util.iterator.****Map1Iterator.hasNext(**
>>>> Map1Iterator.java:50)
>>>> at
>>>> com.hp.hpl.jena.util.iterator.****WrappedIterator.hasNext(**
>>>> WrappedIterator.java:76)
>>>> at
>>>> com.hp.hpl.jena.util.iterator.****FilterIterator.hasNext(**
>>>> FilterIterator.java:55)
>>>> at
>>>> pt.ipp.isep.gecad.crowdflow.****onto2flow.patterns.**
>>>> SubdivisionRequestPattern.****detect(****SubdivisionRequestPattern.****
>>>> java:79)
>>>> at pt.ipp.isep.gecad.crowdflow.****onto2flow.O2F.process(O2F.****
>>>> java:141)
>>>> at pt.ipp.isep.gecad.crowdflow.****onto2flow.O2F.main(O2F.java:****209)
>>>>
>>>>
>>>> In this last test I noticed that the exception only happens when I debug
>>>> and go through the iteration manually step by step after a breakpoint.
>>>> Otherwise it runs ok.
>>>>
>>>>
>>> Different behaviour during debuging normally means there is some timing
>>> dependent problem caused by a race condition between threads. Yet you say
>>> you are running single threaded. Strange.
>>>
>>> 1. Are you absolutely sure there's no other threads running?
>>>
>>> 2. One other way to have debug break your code is to have a
>>> side-effecting
>>> toString method. The debugger will use toString to show objects on the
>>> stack so if one your objects has a toString that indirectly changes the
>>> graph that would do it. Seems unlikely but when you've eliminated the
>>> impossible ...
>>>
>>> 3. Another way to have debug break your code is to have a broken JVM.
>>> Which JVM is this?
>>>
>>> Dave
>>>
>>> Even if it works outside the debug mode, I still think there is
>>> something
>>>
>>>> I
>>>> am missing in the usage of iterators in Jena.
>>>>
>>>> Thank you for your help.
>>>>
>>>>
>>>> On Wed, Sep 11, 2013 at 10:59 PM, Andy Seaborne <[email protected]>
>>>> wrote:
>>>>
>>>> On 11/09/13 22:51, Dave Reynolds wrote:
>>>>
>>>>>
>>>>> Is the underlying graph a plain graph or an InfGraph?
>>>>>
>>>>>> Dave
>>>>>>
>>>>>>
>>>>>> Also
>>>>>
>>>>> * which version of Jena is this?
>>>>> * what's the full stack trace?
>>>>>
>>>>> Andy
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 11/09/13 21:09, Nuno Luz wrote:
>>>>>
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>>>
>>>>>>> Lately, I have been getting some ConcurrentModificationExceptio**
>>>>>>> ****ns
>>>>>>>
>>>>>>>
>>>>>>> while
>>>>>>> testing my code. I searched for possible causes but I only find (the
>>>>>>> usual
>>>>>>> and normal) cases where some kind of inappropriate modification is
>>>>>>> performed to the data set while iterating.
>>>>>>>
>>>>>>> My app is currently single threaded. In this particular piece of
>>>>>>> code,
>>>>>>> where Node and Edge represent a Graph structure, and are coded
>>>>>>> according to
>>>>>>> the Enhanced Node API:
>>>>>>>
>>>>>>> Node n1 = graph.getNode(e.getFromNode().******getElement());
>>>>>>>
>>>>>>>
>>>>>>> ...
>>>>>>> ExtendedIterator<Edge> it = n1.listOutEdges();
>>>>>>> while(n1Edge == null && it.hasNext()) {
>>>>>>> Edge ee = it.next();
>>>>>>> if(ee.getPropertyOfEdge().******equals(n1Prop))
>>>>>>> n1Edge = ee;
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>> I get a ConcurrentModificationExceptio******n on the hasNext()
>>>>>>> method
>>>>>>>
>>>>>>> in the
>>>>>>>
>>>>>>> second iteration, and only when debugging. Since, apparently, no
>>>>>>> modification is done whatsoever, I have no idea where the problem
>>>>>>> might
>>>>>>> reside.
>>>>>>>
>>>>>>> I also get these exceptions in other situations (not in debug mode),
>>>>>>> which
>>>>>>> I have temporarily solved by immediately invoking the toList() method
>>>>>>> of
>>>>>>> the iterator and then working with the list. In all these cases no
>>>>>>> update/delete/insert (modification) is performed to the data.
>>>>>>>
>>>>>>> Since I can no longer fix these with a "hammer", I would really
>>>>>>> appreciate
>>>>>>> it if you could give me some help :-)
>>>>>>>
>>>>>>> Here's the code executed inside the listOutEdges() method:
>>>>>>>
>>>>>>> return getModel().listStatements(******this, O2F.outEdge, (RDFNode)
>>>>>>>
>>>>>>> null)
>>>>>>>
>>>>>>> .mapWith(new ObjectAsMapper(Edge.class))
>>>>>>> .filterKeep(new ObjectNodeCanAs(Edge.class));
>>>>>>>
>>>>>>> ObjectAsMapper and ObjectNodeCanAs are inner classes exactly as those
>>>>>>> found
>>>>>>> in the Enhanced Node API.
>>>>>>>
>>>>>>>
>>>>>>> Thank you!
>>>>>>> Best,
>>>>>>> Nuno Luz
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
