Re: svn commit: r1562562 - in /jackrabbit/oak/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/observation: EventFactory.java EventQueue.java QueueingHandler.java

[Michael Dürig <md...@apache.org>]

On 29.1.14 8:48 , jukka@apache.org wrote:
> Author: jukka
> Date: Wed Jan 29 19:48:47 2014
> New Revision: 1562562
>
> URL: http://svn.apache.org/r1562562
> Log:
> OAK-1332: Large number of changes to the same node can fill observation queue
>


> +        //---------------------------------------------------------< Event >--
> +
> +        @Override
> +        public String getPath() {
> +            return PathUtils.concat(
> +                    mapper.getJcrPath(parent), mapper.getJcrName(name));
> +        }

Being burnt by OAK-1370... but his might also lead to concurrent access 
to the same session from multiple threads. We should probably also 
synchronise the session related part of the NPM.

Michael

Re: svn commit: r1562562 - in /jackrabbit/oak/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/observation: EventFactory.java EventQueue.java QueueingHandler.java

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Thu, Jan 30, 2014 at 10:49 AM, Michael Dürig <md...@apache.org> wrote:
> Being burnt by OAK-1370... but his might also lead to concurrent access to
> the same session from multiple threads. We should probably also synchronise
> the session related part of the NPM.

I'd simply synchronize the entire NPM. Doing so shouldn't cost too
much in the normal case where just a single thread is accessing a
session, but should avoid problems in the cases where there is
concurrent access. In the case of observation this could even happen
with a perfectly valid client that doesn't try to use the session
concurrently from multiple threads, as observation thread will in any
case need to access the NPM.

BR,

Jukka Zitting