EventListener on Event.NODE_ADDED results in InvalidItemStateException

[Simon Gaeremynck <ga...@gmail.com>]

Hi,

I am listening to the repository (at '/' )  to look for files who get
uploaded trough WebDAV.
So I am listening to events of NODE_ADDED for types of nt:file and who are
deep.

When I get such an event I want to add a couple of properties and a mixin on
it.
For each event I create a new session and grab the node at the specified
path (from the event.getPath() method.)

Everything works fine. But as soon as I want to save my session I get an
InvalidItemStateException. [1] Full stacktrace

I think this is probably because there is still some indexing that JCR takes
care of and thus modifies the node as well ?
The strange thing is, that it is the root node who is modified and not the
uploaded file.

For now I have a nasty workaround which just tries to save, catches the
exception (if any) yields the thread and then tries again.
This is obviously not what I want.
Full code can be found at [2]

If it helps I am using Mac OS X 10.6.1 with the built-in WebDAV client in
Finder using java 1.6.0_15

Can anyone shed some light on why I am getting this exception and what I
should do to prevent it?

Kind regards,

Simon


[1]
06.10.2009 11:41:18.075 *ERROR* [ObservationManager]
org.sakaiproject.kernel.files.FileObserver Item cannot be saved because it
has beenmodified externally: node / javax.jcr.InvalidItemStateException:
Item cannot be saved because it has beenmodified externally: node /
    at
org.apache.jackrabbit.core.ItemImpl.getTransientStates(ItemImpl.java:246)
    at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1085)
    at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:846)
    at
org.apache.sling.jcr.base.internal.PooledSession.save(PooledSession.java:256)
    at
org.sakaiproject.kernel.files.FileObserver$1.onEvent(FileObserver.java:114)
    at
org.apache.jackrabbit.core.observation.EventConsumer.consumeEvents(EventConsumer.java:243)
    at
org.apache.jackrabbit.core.observation.ObservationDispatcher.run(ObservationDispatcher.java:145)
    at java.lang.Thread.run(Thread.java:613)
javax.jcr.InvalidItemStateException: Item cannot be saved because it has
beenmodified externally: node /
    at
org.apache.jackrabbit.core.ItemImpl.getTransientStates(ItemImpl.java:246)
    at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1085)
    at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:846)
    at
org.apache.sling.jcr.base.internal.PooledSession.save(PooledSession.java:256)
    at
org.sakaiproject.kernel.files.FileObserver$1.onEvent(FileObserver.java:114)
    at
org.apache.jackrabbit.core.observation.EventConsumer.consumeEvents(EventConsumer.java:243)
    at
org.apache.jackrabbit.core.observation.ObservationDispatcher.run(ObservationDispatcher.java:145)
    at java.lang.Thread.run(Thread.java:613)

[2] http://paste2.org/p/454952

Re: EventListener on Event.NODE_ADDED results in InvalidItemStateException

[Alexander Klimetschek <ak...@day.com>]

On Tue, Oct 6, 2009 at 13:23, Simon Gaeremynck <ga...@gmail.com> wrote:
> If it helps I am using Mac OS X 10.6.1 with the built-in WebDAV client in
> Finder using java 1.6.0_15

> Can anyone shed some light on why I am getting this exception and what I
> should do to prevent it?

> 06.10.2009 11:41:18.075 *ERROR* [ObservationManager]
> org.sakaiproject.kernel.files.FileObserver Item cannot be saved because it
> has beenmodified externally: node / javax.jcr.InvalidItemStateException:
> Item cannot be saved because it has beenmodified externally: node /

I could imagine that there are multiple saves() happening at the
webdav level. The Mac Webdav client for example renames files when it
modifies them, and when creating files, it will create an empty file
first. Since each request will save, you have some intermediary steps
in the JCR that have to be handled.

In this case I think while your event listener handles the first
session.save(), the webdav client again modifies the nodes in question
and saves before your listener, hence you get a conflict.

A solution could be to queue events and wait some time before acting upon them.

Regards,
Alex

-- 
Alexander Klimetschek
alexander.klimetschek@day.com