Roll, Kevin wrote > 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. > Yepp, that's in the works for the next update of Sling :)
Carsten > -----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]
