[jboss-as7-dev] Add Notification support to the domain management API

[Jeff Mesnil]

Le 15 févr. 2013 à 18:33, Brian Stansberry <brian.stansberry at redhat.com> a écrit :

> On 2/15/13 10:36 AM, Jeff Mesnil wrote:
>> 
>> Le 14 févr. 2013 à 23:42, Brian Stansberry <brian.stansberry at redhat.com> a écrit :
>> 
>>> Just some basic categories of use cases:
>>> 
>>> 1) Internal to the server. See usage of ControlledProcessStateService
>>> for an example. It's essentially a notification emitter for a couple
>>> specific management events.
>>> 
>>> A lot of internal to the server use cases though might be better done
>>> with services though. For example, say a service injects a
>>> SocketBindingService to learn it's socket configuration during start.
>>> Then that service wants to listen for notifications of changes to the
>>> socket binding config. Is it better off listening for messages from a
>>> generic notification mechanism, or should the SocketBindingService
>>> itself generate events?
>> 
>> 
>> In this case, I'd still use a generic notification mechanism. The SocketBindingService will have its configuration changes through calls to :add/:remove/:write-attribute operations in any case, right?
>> The service that injects a SocketBindingService could register a listener on the SBS's path address and be notified on any config changes.
>> 
>> I think we could also allow any resource (or service) to generate well-defined notifications too (e.g. when a host joins/leaves a domain) but notifications from :add/:remove/:write-attribute could cover most of the use cases.
>> 
> 
> There's a distinction though between a model change and a runtime change. If I change some attribute on a management resource, that may or may not be relevant to currently running services. Quite often there is no runtime change other than the process is put into reload-required state.
> 
> We need to be very careful about this distinction. If listeners are added for model changes that incorrectly assume there's an equivalent runtime change, and then the listener goes and changes its own runtime, that's where we can have problems.
> 
> Perhaps a generic management notification API is still the right way to handle this, just with extra information in the event that describes the runtime impact. I haven't thought about how hard that would be to do with the current management infrastructure.
> 
> You're on the right track asking about use cases. What is the listener hoping to achieve by getting a notification?


I don't find a compelling use case for internal notifications.
While working on the messaging subsystem, I never thought once "having notifications would be useful to do this or that…". Besides, having resources listening to each other through notifications could open a whole can of worms and conflict with service dependencies. I'm not sure to grasp the whole implication...

We have only 2 use cases of PropertyChangeSupport in AS7 that could be replaced by internal notifications. In ControlledProcessStateService as you mentioned and in web's ClusteredSession (but the support instance if private and nobody is registered on it). Introducing a general notification mechanism just for these 2 seems overkill.

Unless I can come up with compelling use cases for internal notifications, I'll put them aside and focus on external notifications (that can be consumed through the Java/HTTP management API).

-- 
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/