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
