[http whiteboard] provide for an http whiteboard listener to track (un)registration of http whiteboard services

[bjhargrave]

Original bug ID: BZ#2916 From: @rotty3000 Reported version: R7

[bjhargrave]

Comment author: @rotty3000

While the whiteboard pattern is great at decoupling whiteboard runtimes from their clients, the out of band nature of the (un)registration process can leave developers guessing as to when/where/how their services were actually detected or released by the whiteboard runtime.

I'd like to propose an HttpWhiteboardListener interface which would have methods something like addedService(DTO)/removedService(DTO).

Furthermore, since the HTTP Whiteboard already has every well defined DTOs for all of it's services, as well as their failure conditions, it seems plausible to use these as the event payload. It gives the listener awareness of not only the event type, but the state/reason in the case of failure.

[bjhargrave]

Comment author: @rotty3000

This was discussed in the context of RFP-182 as section 4.4 Whiteboard Marking but for which it was decided that a "readiness" service which indicates the availability of services from the perspective of the whiteboard implementation.

The will be discussed in the RFC-223.

Further, we will discuss it also w.r.t. JAX-RS which will present the same problem.

[bjhargrave]

Comment author: @rotty3000

At the community event, Balázs Zsoldos (Everit) presented the ECM framework, which is a custom DS-like component framework.

A significant motivation came from observation that the whiteboard pattern was lacking an event indicating a whiteboard's "acknowledgement" of a service.

Since we had already observed this, I think it would be good to discuss this aspect.

[bjhargrave]

Comment author: @cziegeler

I assume we are discussing this in the light of the Service Decorators

[bjhargrave]

Comment author: @rotty3000

Ray's going to boil down requirements particular to Http Whiteboard in order to not conflate the problem before discovering a solution.

[bjhargrave]

Comment author: @bjhargrave

See https://osgi.org/gitweb/build.git/commit/b30f952cf98e85bd887ede76b6cc9f441214b5f7 where I add the service.changecount service property to the core spec. HttpServiceRuntime must register with the service property and update it whenever the http runtime DTOs change.

DS spec has been updated to use this same service property for the ServiceComponentRuntime service. See https://osgi.org/gitweb/build.git/commit/06e9aa9124f1b2352f0a010c461b7075670799f3.

[bjhargrave]

Comment author: @rotty3000

I don't see a way to avoid update storms since most whiteboards operate on individual services and therefore have no real context for batching operations.

Is there a way to address this?

[bjhargrave]

Comment author: @bjhargrave

(In reply to Raymond Auge from comment BZ#6)

I don't see a way to avoid update storms since most whiteboards operate on individual services and therefore have no real context for batching operations.

Is there a way to address this?

It is up to the implementation do decide when to update the service property. For example, SCR could do it after each bundle, configuration, etc., change is processed. HttpWhiteboard could do it 5 seconds after the last change occurs (to have some grouping).

The implementation can choose what works best for it. There is no requirement for the update to be done in real time.

[bjhargrave]

Comment author: @cziegeler

(In reply to BJ Hargrave from comment BZ#7)

(In reply to Raymond Auge from comment BZ#6)

I don't see a way to avoid update storms since most whiteboards operate on individual services and therefore have no real context for batching operations.

Is there a way to address this?

It is up to the implementation do decide when to update the service property. For example, SCR could do it after each bundle, configuration, etc., change is processed. HttpWhiteboard could do it 5 seconds after the last change occurs (to have some grouping).

That's how I implemented it in the Felix implementation. So for whatever happens within the 5 seconds, only one update is done.

The implementation can choose what works best for it. There is no requirement for the update to be done in real time. Don't want to be picky but wouldn't this mean we have to add it to the docs in some way? I think it currently says something like "the change count is updated on every change". Which would mean there are three updates of that property if three changes happen. With the improvement mentioned above, only one update happens.

[bjhargrave]

Comment author: @bjhargrave

(In reply to Carsten Ziegeler from comment BZ#8)

The implementation can choose what works best for it. There is no requirement for the update to be done in real time. Don't want to be picky but wouldn't this mean we have to add it to the docs in some way? I think it currently says something like "the change count is updated on every change". Which would mean there are three updates of that property if three changes happen. With the improvement mentioned above, only one update happens.

It doesn't define "change". The point of the Long value is to denote that things are different since before. So incrementing the Long by 1 does not mean only one DTO changes. It could mean all DTOs changed.

The value can be useful for polling too. You can poll the value every 30 sec and if has changes (by any amount) since you last looked, you know there are some changes.

So for batching updates, you only need to increment by 1. Or you can increment by any number you want. It just needs to monotonically increase!

[bjhargrave]

Comment author: @bjhargrave

Ray, does the RFC already cover this? (asked of you as 1 Jun 2017 CPEG call).

[bjhargrave]

Comment author: @cziegeler

For reference, the updated spec already contains the changeCount property - I think that's all we should do

[bjhargrave]

Comment author: @bjhargrave

OK, then I'll close this bug.