Hi,
Oak would support (most of) this through OAK-1133 [1] as mentioned
earlier [2].
Michael
[1] https://issues.apache.org/jira/browse/OAK-1133
[2] http://markmail.org/message/zmwhp7a7tshtfvob
On 19.10.15 4:38 , Ian Boston wrote:
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]
