[wildfly-dev] WFCORE-1405 - Notification Registrars

[Brian Stansberry]

On 6/16/16 8:42 AM, Kabir Khan wrote:
>
>> On 16 Jun 2016, at 10:29, Kabir Khan <kabir.khan at jboss.com> wrote:
>>
>>
>>> On 16 Jun 2016, at 10:29, Kabir Khan <kabir.khan at jboss.com> wrote:
>>>
>>>
>>>> On 15 Jun 2016, at 23:19, Kabir Khan <kabir.khan at jboss.com> wrote:
>>>>
>>>> I have written up analysis/design notes for the new notification registrar mechanism at https://developer.jboss.org/wiki/DesignNotesForAbilityToRegisterAListenerintegratedWithTheManagementLayerThatWillBeNotifiedOfTheLifecycleServerEventsNotificationRegistrars
>>>>
>>>> My main doubt is about the usefulness of the NotificationRegistrarContext.getModelControllerClient() method.
>> The only reason this is there is it was there in Brian's original draft. I think I'd like to remove it for now
> Unless the intent is to do something along the lines of when something happens in subsystem A to modify some resources elsewhere?

The reason for this is just that the only reason to receive a 
notification is to in turn take some action. So unless whatever they 
want to do has nothing to do with the rest of the system, they must:

1) Update the state of the MBeanServer, affecting JMX domains other than 
jboss.as[.expr].  This kind of thing is what was specifically mentioned 
by users in some of the discussions that led to this.

2) Take some action affecting the management resources, either via the 
ModelController or via the jboss.as[.expr] mbeans. Perhaps deploy 
something or...

3) Hack at MSC services via something like CurrentServiceContainer.

4) Update some state stored in static fields, which can then be read by 
other code of theirs that has access to the field.

I think it's ok to not support 2) for now; we can see if people ask for 
it with a concrete use case. That said I think it's not good if we can't 
support it by making these notifications truly asynchronous to the 
operation that spawns them. Not providing a ModelControllerClient isn't 
going to block people using the jboss.as[.expr] mbeans, so the problem 
still exists, it's just more hidden.

We don't want people doing 3) as its not a supported API. People who 
want to do that should write a subsystem. Same with 4) although at least 
there they aren't hacking our code, just their own.


>>>> The NotificationRegistrarContext is used by NotificationRegistrar.registerNotificationListeners(), which in turn is called by a service's start() method. The service is installed by an add handler. Is my memory of calling the ModelControllerClient execute methods at this stage a bad thing correct? I mention that the MCC can be cached for later use by the handlers, which on one hand I think should be ok since the handlers are executed on asynchronously,
>>> Actually, WFCORE-1157 makes the server state lifecycle events synchronous, so the above isn't 100% true
>>>> but on the other hand having notification handlers mess around with the model seems a bit strange as well.
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat