On Mon, Oct 21, 2013 at 6:47 PM, Jukka Zitting <jukka.zitt...@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
