Hi, On Wed, Nov 6, 2013 at 8:49 PM, Alexander Klimetschek <[email protected]> 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
