Hi, Just my 2p. I think we should get away from generic catch all event generation and move to specific event generation designed for purpose.
What do I mean by that ? In a repository, there might be 50M generic events generated every hour. If the application only responds to 1K of those events, that is wasting a huge amount of resource that could be used to scale everything further on a particular platform. Distributing that volume of events into a cluster will just consume resources. The JSP case is a good example. A generic system sends an event out for every modification to a Node in the repository. All receivers filter selecting the information of interest. So the JSP change listener has to listen to millions of events it has no interest in, even if that filter is applied centrally. A specific event generation system would generate the event on a specific channel and the distribution mechanism would only need to send it to a small number of listeners (1 per JVM probably). The volume of events generated is orders of magnitude less, but it requires that the code performing modifications has to explicitly generate events. If thats too hard, a bridge between JCR Observation -> channels could be used, only populate channels with known listeners. Ideally to get full benefit, code would send the event, compliant to a well documented dictionary of channels and repository observation be deprecated completely. Best Regards Ian On 19 October 2015 at 15:14, Carsten Ziegeler <[email protected]> wrote: > Am 19.10.15 um 15:57 schrieb Stefan Egli: > > Hi, > > > > I think it could be useful to have a broader overview of use cases and > > have them categorised. What comes to mind besides the cache-invalidation > > case you mentioned (which I think is still a good candidate for external > > observation events) is: > > > > * exactly once : eg when uploading an asset you want a certain job to be > > started exactly once. Currently this uses internal events only (so kind > > of not related to this external event topic) but it has the risk of > > failing when the instance crashes before the job was created. Perhaps > > we could add some framework support for this (auto-creation of a job?) > > Uh, you're opening another can of worms :) But I see your point, now the > only thing that really works is creating the job within the save > operation of the asset. Everything that happens after the save can > already be too late. This would basically mean: we send out observation > events before the save and allow additional operations. We could handle > this from within the resource resolver implementation. > > > > > * maybe there's also at-least-once, not sure, but it might also be > > solved with auto-spawning a job (perhaps less costly than exactly-once) > I think this is more on the processing side of jobs, not really > observation. > > > > > If we're comfortable having covered all use cases we can probably disable > > external observation event support entirely - but until then, even > > switching > > the default to be internal-only would probably reduce external events a > > lot. > > With the new observation api we have the marker interface, so basically > we know which events need to be sent across the wire. But still, it > would be great if we can avoid this completely. Even for the caching use > case. > > Regards > Carsten > -- > Carsten Ziegeler > Adobe Research Switzerland > [email protected] >
