I've realized this is coming from a slightly different direction than I
thought. The trouble began when I added a new TOPIC_RESOURCE_CHANGED handler
that works alongside an existing TOPIC_RESOURCE_ADDED handler. The exception
trace looks like this:
javax.jcr.InvalidItemStateException: Item does not exist anymore:
32b1cc4d-eb62-4a51-8a06-857369fb6b35
at
org.apache.jackrabbit.core.ItemImpl.itemSanityCheck(ItemImpl.java:116)
at org.apache.jackrabbit.core.ItemImpl.sanityCheck(ItemImpl.java:104)
at
org.apache.jackrabbit.core.NodeImpl.getPrimaryNodeType(NodeImpl.java:2337)
at
org.apache.sling.jcr.resource.internal.helper.jcr.JcrItemResource.getResourceTypeForNode(JcrItemResource.java:121)
at
org.apache.sling.jcr.resource.internal.helper.jcr.JcrNodeResource.getResourceType(JcrNodeResource.java:95)
at
org.apache.sling.jcr.resource.internal.JcrResourceListener.processOsgiEventQueue(JcrResourceListener.java:351)
I had not realized the significance of that last line - this is not my code but
the event processing thread. After some investigation I realized that BOTH of
these event handlers are triggered simultaneously under certain conditions, and
they run on separate threads. They do not do any Resource modification, but
they do both look at the same Resource and create instances of the same Job
class. Synchronizing that Job creation did not help, but I think there is some
sort of concurrency problem related to these event handlers. Does that sound
plausible?
-----Original Message-----
From: Carsten Ziegeler [mailto:[email protected]]
Sent: Friday, November 20, 2015 11:39 AM
To: [email protected]
Subject: Re: ResourceResolver and thread safety
Am 20.11.15 um 09:10 schrieb Roll, Kevin:
> OK, allow me to broaden the question. We are getting mysterious repository
> corruption as previously detailed. I'm fairly certain that this is related to
> a task I have that scans Resources and sets some node properties but I can't
> pin down what I might be doing wrong. Are there any common mistakes that
> might cause the "Item does not exist anymore" exception? I can describe my
> code in more depth if that would help, but it is rather involved.
This can have several reasons. Usually when I'm seeing this it happens
that concurrent resource resolvers are involved. While for example one
resolver traverses a tree, another one is modifying it.
Carsten
