jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tobias Bocanegra <tri...@apache.org>
Subject Re: Observation
Date Thu, 07 Nov 2013 18:12:31 GMT
On Thu, Nov 7, 2013 at 5:46 AM, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> Hi,
>
> On Wed, Nov 6, 2013 at 8:49 PM, Alexander Klimetschek
> <aklimets@adobe.com> wrote:
>> 1) listeners should not get external events by default
>
> I'd rather not make such a default. A component designed to process
> local changes should in most cases be implemented as a commit hook,
> not an observation listener.

I disagree. the commit hook is executed before the commit - which
still can fail. Also, the commit hook is highly inconvenient to use.
what you really want are nicely aggregated observation events :-)

regards, toby

> And for backwards compatibility with
> existing JCR listeners we in any case need to keep the external events
> included by default.
>
>> 4) listener threads
>>
>> Currently in oak each event listener gets its own thread. In our app CQ
>> we have about 150 listeners, so you end up introducing 150 threads.
>> I am not sure if this is a good idea.
>
> I would say the problem here is the number of listeners, not the
> number of threads.
>
>> An obvious solution would be a thread pool (probably configurable number of
>> threads). And on top of that, if the pool is full and no thread is free anymore,
>> one could simply kill blocked handlers after a certain timeout (and
>> optionally blacklist them).
>
> I don't see a major benefit over simply having a separate thread for
> each listener, just a extra complexity, especially since killing
> blocked threads is nasty business in Java.
>
>> 5) filtering in central thread?
>> [...]
>> I guess it is that reading asynchronously from the immutable NodeStates
>> is more efficient than multiple blocking queues. Which speaks good for
>> the underlying oak implementation :)
>
> Right, that's what it was designed for. :-) See my post
> (http://markmail.org/message/ckmphhdfehbb3qkw) in the related thread
> for an explanation; the incremental cost of doing a repeated content
> diff is much smaller than that of the first diff, so especially on a
> system with multiple cores it makes more sense to do a bit of repeated
> work in parallel instead of relying on a central thread for
> pre-processing. The added benefit is that there is no risk of an event
> queue to grow without bounds because of a blocked listener.
>
>> 6) long-running session just for observation
>> [...]
>> Or you keep the session, but mark it in a special way so that Oak
>> can internally save resources. Or maybe the session in oak is already
>> so light-weight that this is actually no problem at all.
>
> The latter. Unlike with Jackrabbit 2.x, adding a new session does not
> slow down all the existing ones. The warning for long-lived sessions
> is there just to remind people to use refresh() in such cases (though
> with the auto-refresh mode the warning is kind of moot).
>
>> 7) move code to oak-jcr (minor)
>
> Agreed.
>
> BR,
>
> Jukka Zitting

Mime
View raw message