Hi Bertrand, I'm not so sure about the seldom changes - it is not about the amound of changes but about the amount of changes in a specific timeframe. The initial discussion started with the asumtion to have to deal with tons of changes within a second, e.g. for huge imports. In some cases those imports are real imports (so new creation) so postponing the processing and delegating to some postprocessing might work - but in case of updates this is not so easy (and I know such cases from the automotive area where masses of technical data is synched to all markets).
Regarding the options you were stating: - service properties: my initial thought, but static and can therefore not adress all scenarios - registring for certain types: same problem, a bit more possibilities but restricted to the capabilities of the registry Therefore I thought of a filterlike behavior where the listeners can implement their own logic. Including measuring the time such a call takes and having a healthcheck announcing such a logic not to be performing well would be a good way to give developers the tooling to identify where they lose performance in this area. --- Dominik On Wed, Oct 23, 2013 at 4:19 PM, Bertrand Delacretaz <[email protected] > wrote: > Hi, > > On Wed, Oct 23, 2013 at 4:01 PM, Dominik Süß <[email protected]> > wrote: > > ...This might not apply to the whole > > tree, but does this really matter when the tree that needs to be watched > > contains over 90% of the data?... > > What's important is the frequency of observation events - if that 90% > seldom changes, scaling won't be a problem. > > > ...If I got the problem right the overhead is created by the fact that an > > event object is created and sent regardles if a consumer cares about it > or > > not. So it might be worth to add something that "asks" the listeners if > > there is one that would consume this event... > > That's what I meant above: > > > ...A simple way of making our wide observation more specific is to > > require users of our rebroadcast OSGi events to indicate more > > specifically what they're interested in... > > There's various ways of doing that: service properties, calling a > service to register your interest in certain types of events etc. > > -Bertrand >
