Thanks for the confirmation, Carsten... we will ignore these warnings. It seems a bit odd to me that the event handler triggers when a job is modified; I understand the "everything is a Resource" philosophy, but in my mind the job is not part of my data, it's a Sling internal. Somebody probably has a use case where they want to see this but for our app it's just noise. It would be nice to be able to annotate the EventHandler and filter down the things it will actually respond to.
-----Original Message----- From: Carsten Ziegeler [mailto:[email protected]] Sent: Wednesday, November 25, 2015 8:13 AM To: [email protected] Subject: Re: ResourceResolver and thread safety Roll, Kevin wrote > Even more interesting: > > 12:28:00.502 INFO [Thread-33] <c.i.l.r.e.ResourceAddedHandler> OSGi resource > added event received: > /var/eventing/jobs/assigned/db2af778-5713-4723-ad27-12cd89d2ddb0/com.idexx.labstation.repository.fileuploaded.job/2015/11/24/12/28/com.idexx.labstation.repository.fileuploaded.job_db2af778-5713-4723-ad27-12cd89d2ddb0_2345 > 12:28:00.518 ERROR [Apache Sling JCR Resource Event Queue Processor] > <o.apache.jackrabbit.core.ItemManager> f3092eb9-f31e-4299-a976-01caf508018d: > failed to determine path to > 12:28:00.520 ERROR [Apache Sling JCR Resource Event Queue Processor] > <o.a.s.j.r.i.h.jcr.JcrNodeResource> Unable to get resource type for node node > f3092eb9-f31e-4299-a976-01caf508018d > javax.jcr.InvalidItemStateException: Item does not exist anymore: > f3092eb9-f31e-4299-a976-01caf508018d > 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 looked at the code in JcrResourceListener and it is simply trying to get > the resource type for the node that triggered the TOPIC_RESOURCE_ADDED > handler. But, the thing that triggered the event handler is a *job*, and > presumably it may have been processed and removed in the short time before > the event handler runs. Is this possibly a bug in Sling? > The above error can be ignored, unfortunately afaik we can't surpress logging it. What happens is exactly as you assume: the resource listener is trying to process an event for a resource and before it gets to the point of processing it (getting the resource type), someone else already removed that node. This can happen, is nothing dramatic, but just looks wired in the logs. If you run the integration tests for the job module in Sling, you'll notice a lot of those messages. But the tests proof that the functionality is not affected by it Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland [email protected]
