jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chetan Mehrotra <chetan.mehro...@gmail.com>
Subject Re: Oak JCR Observation scalability aspects and concerns
Date Tue, 22 Oct 2013 09:14:50 GMT
On Mon, Oct 21, 2013 at 6:47 PM, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> -1 This introduces the problem where a single JCR event listener can
> block or slow down all other listeners.

That can be mitigated upto an extent by using some sort of Black List
(OAK-1084). However current approach of each listener pulling in the
diff at its own pace is more robust to handle such cases.


> I'm not convinced by the assumption here that the observation
> listeners put undue pressure on the underlying MK or its caching. Do
> we have some data to prove this point? My reasoning is that if in any
> case we have a single (potentially multiplexed as suggested) listener
> that wants to read all the changed nodes, then those nodes will still
> need to be accessed from the MK and placed in the cache. If another
> listener does the same thing, they'll most likely find the items in
> the cache and not repeat the MK accesses. The end result is that the
> main performance cost goes to the first listener and any additional
> ones will come mostly for free, thus the claimed performance benefit
> of multiplexing observers is IMHO questionable.
>

Agreed (and also mentioned earlier) that current approach does cause
multiple calls to MK as in most cases the NodeState would be found in
the cache. However due the access pattern i.e. same node state being
fetched multiple times such entries in cache would get higher priority
and occupy memory which would otherwise would have been used to cache
NodeState for *latest* revision.

This is just an observation and I currently do not have any numbers
which indicate that this would cause significant performance issue and
further such things are hard to measure.

Chetan Mehrotra

Mime
View raw message