jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Re: Observation
Date Thu, 07 Nov 2013 13:46:06 GMT
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. 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