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()?
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
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
