On Thu, Nov 7, 2013 at 5:46 AM, Jukka Zitting <[email protected]> wrote: > 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.
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
