Proposal to add notifications to WildFly management model and API

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

Proposal to add notifications to WildFly management model and API

Jeff Mesnil
# Add Notification support to WildFly Management

Tracked by https://issues.jboss.org/browse/WFLY-266

Use Cases
---------

Notifications are an useful mechanism to observe management changes on WildFly servers.
It allows an administrator to be informed of changes outside of his own actions (e.g. a server has been killed, a new application is deployed, etc.)

Currently WildFly lacks notifications and users that were depending on JMX notifications in previous versions have no similar feature to use.

The most expected use cases for WildFly notifications are:
- enhance UX for Web console. Using notifications, the Web console could notify the users of changes outside its own actions.
- replacement for JMX notifications. Users that were listening for JMX notifications to observe management changes would have a similar feature using WildFly own notifications
- integration with JMX. Notifications emitted by WildFly could be converted and made available using JMX notifications (including notifications for mbean registered/unregistered)

Part 1: Notification Definition
-------------------------------

A resource will define the notifications it emits. These definitions will be added to the attributes and operations definitions on a resource.

      {  
          "description" => "A manageable resource",  
          "attributes" => {  
             ...  
          },  
          "operations" => {  
             ...  
          },  
          "notifications" => {  
             "resource-added" => {
                ...  
             }  
          },  
          "children" => {  
             ...  
          }  
       }  

The description of a notification will be composed of:

* type - String - the type of notification (resource-added, server-stopped, etc.)
* description - String - i18ned description of the notification
* access-constraints - the RBAC access constraints that controls who can receive the notifications
* data-type - ModelType or complex structure - optional - only present if the notification will have a data value. data-type will detail the structure of the data value, enumerating the value's fields and the type of their value

The read-resource-description will be enhanced with a notifications parameter (boolean) to include the notifications descriptions (default value is false, same as the operations parameter).

The ManagementResourceRegistration interface will be enhanced to register a notification definition with registerNotification(NotificationDefinition notification). The NotificationDefinition interface corresponds to the detyped representation of a notifications and comes with a builder API.

Part 2: Emitting a notification
-------------------------------

A notification can be emitted in any OperationStepHandler using the OperationContext.emit(Notification method)

    public void execute(OperationContext context, ModelNode operation) throws OperationFailedException {

       // perform some actions
       ...
   
       context.emit(new Notification(SERVER_RESTARTED_NOTIFICATION, address, ROOT_LOGGER.serverHasBeenRestarted()));
       context.stepCompleted();
    }

The notification is *not* emitted (i.e. delivered to interested parties) when OperationContext.emit() is called. It is emitted at the end of the operation step only if it is successful. A call to OperationContext.emit() will have no effect if the operation is rolled back.
Notification emission is done asynchronously using the server thread pool and does not block the execution of the operation that triggered the notification: having zero or any notification handlers must have no impact of the execution of the operation.

A Notification is a simple Java class that represents the notification. It is composed of:

* type - String - the notification type
* address - PathAddress - the address of the resource that emits the notification
* message - String - the i18ned description of the message
* timestamp - long - the timestamp of the notification. It is set when the Notification object is created.
* data - ModelNode - optional - a detyped representation of data associated to the notification. If a notification includes a data field, its definition must describe it (in its data-type parameter).

If RBAC is enabled, the notification access-constraints will be checked to ensure that the handler have the required privileges to receive the notification. Notification will potentially contain critical information (e.g. if a security-credential attribute is updated, the notification will contain its old and new values) and must be constrained accordingly.

Part 3: Global Resource Notifications
——————————————————

In the same way that some operations are available for any resource (e.g. add, remove, read-resource-description), some notifications will be added to any resource of WildFly management model:

* resource-added - when a resource is added, it emits a resource-added notification
* resource-removed - when a resource is removed, it emits a resource-removed notification
* attribute-value-written - when a write-attribute operation is performed successfully on a resource, it emits a attribute-value-written    notification. The notification's data field contains the following information:
  * name - String - the name of the attribute
  * old-value - the detyped representation of the previous value of the attribute
  * new-value - the detyped representation of the new value


Part 4: Notification Handlers
——————————————

Any interested parties can receive notifications by registering a NotificationHandler using the ModelController.getNotificationSupport().registerNotificationHandler(source, handler, filter) method.

The source is a path address to handle notifications emitted by resources at this address.
The NotificationHandler is an interface with a single handleNotification(Notification notification) method.
The isNotificationEnabled(Notification notification) is an interface with a single isNotificationEnabled(Notification notification) method to filter out uninteresting notifications.

There is a similar unregister method to unregister a (handler, filter)

To be useful, the source path address will have to accept wildcards for the address' values:
* /subsystem=messaging/hornetq-server=* to receive notifications emitted by any hornetq-server resources
* /subsystem=messaging/hornetq-server=*/jms-queue=* to receive notifications emitted by any jms-queue on any hornetq-server resources

Wildcards for address' keys or key/value paris are not allowed (/subsystem=messaging/*=*/jms-queue=* and /subsystem=messaging/*/jms-queue=* are not valid).

This notion of wildcard for the resource addresses should be made to match current usage (e.g. in the CLI).

The main reason for the wildcard is for the resource-added/resource-removed notifications. I find more intuitive to have the notifications at the same resource-level than their corresponding add/remove operations. However until the resource is created, there is no way to register a notification listener on it without using a wildcard.
If that proves problematic, we could change this approach with two alternatives:
* have a single well-known resource emit the notifications for all resource (that's the JMX approach). A likely candidate would be /core-service=management
* the resource-added/-removed notifications can be emitted by the resource parents (but it only fixes the issue for the last leaf of the address tree…)

I still have questions about RBAC enforcements and it is possible that the registration of a handler will have to be done with additional metadata identifying the user roles wrt RBAC...

Part 5: Domain Notifications
——————————————

Notifications are also intended to work in domain mode. In particular, they will be used to observe server state.

The following notifications will be emitted by resources at /host=XXX/server-config=YYY (i.e. the resource to start/stop/etc. a server):
* server-started
* server-stopped
* server-restarted
* server-destroyed
* server-killed

Part 6: Integration with local JMX
—————————————————

The jmx subsystem will be updated to leverage the WildFly notifications and expose them as MBean notifications in our jmx facade for the management model:
* the WildFly notification description will be converted to MBeanNotificationInfo and added to the MBeanInfo
* when a JMX notification listener is added to an ObjectName, a WildFly NotificationHandler will be added to the path address corresponding to the ObjectName.
* depending on the user feedback, we may provide a hack to convert some WildFly notifications to their well-known JMX equivalent notifications (e.g. resource-added => jmx.mbean.registered).

In a first step, integration will be limited to use of JMX locally. Remoting will not be supported.

Part 7: Integration with Remote Management API
———————————————————————

We will enhance the remote management native API to register/unregister a notification handler from the ModelControllerClient

    void registerNotificationHandler(ModelNode resourceAddress, NotificationClientHandler handler, NotificationClientFilter filter);

The client contract will have to taken into account reconnection when server is reloaded (possibly by caching the handler & filter and register them again after reconnection to the server...)

The Management HTTP API will also be enhance to support notifications with its REST API.
A neat addition will be to provide a browser-specific way to push notifications to the browser (e.g. using Server-Sent Events or Web Sockets).
=> the Web Console is the recipient for this feature and will have their say in how they prefer to consume notifications

Part 8: Integration with Remote JMX
—————————————————

Once the WildFly Management API will support notifications (for both native and HTTP), we can add support to JMX remotely (if there is any user interest for it).

Part 9: Web Console UX improvement
—————————————————

Once the Management HTTP API supports notifications, the Web console can leverage it to improve its UX.

This is a task that touch different parts of the app server (mainly in wildfly-core though) and I intend to split it in different JIRA issues (approx. one for each part) that can be merged one after the other instead of a big huge commit.

What do you think?

jeff


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


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to add notifications to WildFly management model and API

Thomas Segismont
Le 07/07/2014 16:46, Jeff Mesnil a écrit :

> Part 7: Integration with Remote Management API
> ———————————————————————
>
> We will enhance the remote management native API to register/unregister a notification handler from the ModelControllerClient
>
>      void registerNotificationHandler(ModelNode resourceAddress, NotificationClientHandler handler, NotificationClientFilter filter);
>
> The client contract will have to taken into account reconnection when server is reloaded (possibly by caching the handler & filter and register them again after reconnection to the server...)
>
> The Management HTTP API will also be enhance to support notifications with its REST API.
> A neat addition will be to provide a browser-specific way to push notifications to the browser (e.g. using Server-Sent Events or Web Sockets).
> => the Web Console is the recipient for this feature and will have their say in how they prefer to consume notifications

Hi Jeff,

Just to let you know, in the RHQ team we're also interested in this
part, as our Wildfly monitoring is based on the HTTP management
interface. I hope we'll be able to find a solution which works nicely
with Javascript as well as Java clients.

Regards,
Thomas
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to add notifications to WildFly management model and API

Brian Stansberry
In reply to this post by Jeff Mesnil
On 7/7/14, 9:46 AM, Jeff Mesnil wrote:

> # Add Notification support to WildFly Management
>
> Tracked by https://issues.jboss.org/browse/WFLY-266
>
> Use Cases
> ---------
>
> Notifications are an useful mechanism to observe management changes on WildFly servers.
> It allows an administrator to be informed of changes outside of his own actions (e.g. a server has been killed, a new application is deployed, etc.)
>
> Currently WildFly lacks notifications and users that were depending on JMX notifications in previous versions have no similar feature to use.
>
> The most expected use cases for WildFly notifications are:
> - enhance UX for Web console. Using notifications, the Web console could notify the users of changes outside its own actions.
> - replacement for JMX notifications. Users that were listening for JMX notifications to observe management changes would have a similar feature using WildFly own notifications
> - integration with JMX. Notifications emitted by WildFly could be converted and made available using JMX notifications (including notifications for mbean registered/unregistered)
>
> Part 1: Notification Definition
> -------------------------------
>
> A resource will define the notifications it emits. These definitions will be added to the attributes and operations definitions on a resource.
>
>        {
>  "description" => "A manageable resource",
>            "attributes" => {
>     ...
>            },
>  "operations" => {
>     ...
>            },
>  "notifications" => {
>     "resource-added" => {
>        ...
>     }
>  },
>  "children" => {
>     ...
>            }
>         }
>
> The description of a notification will be composed of:
>
> * type - String - the type of notification (resource-added, server-stopped, etc.)
> * description - String - i18ned description of the notification
> * access-constraints - the RBAC access constraints that controls who can receive the notifications
> * data-type - ModelType or complex structure - optional - only present if the notification will have a data value. data-type will detail the structure of the data value, enumerating the value's fields and the type of their value
>
> The read-resource-description will be enhanced with a notifications parameter (boolean) to include the notifications descriptions (default value is false, same as the operations parameter).
>
> The ManagementResourceRegistration interface will be enhanced to register a notification definition with registerNotification(NotificationDefinition notification). The NotificationDefinition interface corresponds to the detyped representation of a notifications and comes with a builder API.
>
> Part 2: Emitting a notification
> -------------------------------
>
> A notification can be emitted in any OperationStepHandler using the OperationContext.emit(Notification method)
>
>      public void execute(OperationContext context, ModelNode operation) throws OperationFailedException {
>
>         // perform some actions
>         ...
>
>         context.emit(new Notification(SERVER_RESTARTED_NOTIFICATION, address, ROOT_LOGGER.serverHasBeenRestarted()));
>         context.stepCompleted();
>      }
>
> The notification is *not* emitted (i.e. delivered to interested parties) when OperationContext.emit() is called. It is emitted at the end of the operation step only if it is successful. A call to OperationContext.emit() will have no effect if the operation is rolled back.

To clarify: I believe your intent was delivery is at the end of the
overall operation execution, when it commits, not at the end of the
"operation step". I mention this because an operation execution can
consist of many steps, with even a basic write involving 2 or 3.

> Notification emission is done asynchronously using the server thread pool and does not block the execution of the operation that triggered the notification: having zero or any notification handlers must have no impact of the execution of the operation.
>
> A Notification is a simple Java class that represents the notification. It is composed of:
>
> * type - String - the notification type
> * address - PathAddress - the address of the resource that emits the notification
> * message - String - the i18ned description of the message
> * timestamp - long - the timestamp of the notification. It is set when the Notification object is created.
> * data - ModelNode - optional - a detyped representation of data associated to the notification. If a notification includes a data field, its definition must describe it (in its data-type parameter).
>
> If RBAC is enabled, the notification access-constraints will be checked to ensure that the handler have the required privileges to receive the notification. Notification will potentially contain critical information (e.g. if a security-credential attribute is updated, the notification will contain its old and new values) and must be constrained accordingly.
>

We also need to use SecurityManager permissions around the handler
registration. Non-remote registrations basically get all permissions,
same as internal management clients like the deployment-scanner do. We
control the ability of internal management clients like the scanner to
create a ModelControllerClient using SecurityManager permissions.

> Part 3: Global Resource Notifications
> ——————————————————
>
> In the same way that some operations are available for any resource (e.g. add, remove, read-resource-description), some notifications will be added to any resource of WildFly management model:
>
> * resource-added - when a resource is added, it emits a resource-added notification
> * resource-removed - when a resource is removed, it emits a resource-removed notification
> * attribute-value-written - when a write-attribute operation is performed successfully on a resource, it emits a attribute-value-written    notification. The notification's data field contains the following information:
>    * name - String - the name of the attribute
>    * old-value - the detyped representation of the previous value of the attribute
>    * new-value - the detyped representation of the new value
>

>
> Part 4: Notification Handlers
> ——————————————
>
> Any interested parties can receive notifications by registering a NotificationHandler using the ModelController.getNotificationSupport().registerNotificationHandler(source, handler, filter) method.
>
> The source is a path address to handle notifications emitted by resources at this address.
> The NotificationHandler is an interface with a single handleNotification(Notification notification) method.
> The isNotificationEnabled(Notification notification) is an interface with a single isNotificationEnabled(Notification notification) method to filter out uninteresting notifications.
>
> There is a similar unregister method to unregister a (handler, filter)
>
> To be useful, the source path address will have to accept wildcards for the address' values:
> * /subsystem=messaging/hornetq-server=* to receive notifications emitted by any hornetq-server resources
> * /subsystem=messaging/hornetq-server=*/jms-queue=* to receive notifications emitted by any jms-queue on any hornetq-server resources
>
> Wildcards for address' keys or key/value paris are not allowed (/subsystem=messaging/*=*/jms-queue=* and /subsystem=messaging/*/jms-queue=* are not valid).
>
> This notion of wildcard for the resource addresses should be made to match current usage (e.g. in the CLI).
>
> The main reason for the wildcard is for the resource-added/resource-removed notifications. I find more intuitive to have the notifications at the same resource-level than their corresponding add/remove operations.

Agreed. I don't think this should be an issue. We shouldn't use the
Resource tree anyway as the data structure for retaining the registered
handlers; a separate structure is needed. The wildcards are fine as long
as there's a relevant ManagementResourceRegistration.

> However until the resource is created, there is no way to register a notification listener on it without using a wildcard.
> If that proves problematic, we could change this approach with two alternatives:
> * have a single well-known resource emit the notifications for all resource (that's the JMX approach). A likely candidate would be /core-service=management
> * the resource-added/-removed notifications can be emitted by the resource parents (but it only fixes the issue for the last leaf of the address tree…)
>
> I still have questions about RBAC enforcements and it is possible that the registration of a handler will have to be done with additional metadata identifying the user roles wrt RBAC...
>

It's not critical until you get to Part 7 but we'll need to sort it out
before even starting on Part 7.

The user-related inputs into the existing RBAC logic (see
org.jboss.as.controller.access.Authorizer) are the Caller and
Environment. The Caller basically just wraps a Subject, exposing the
data from the relevant Principal types (name and groups).

We could just cache the Caller in effect when the handler is registered
and use it for authorizing delivery of each notification. The problem is
if the user if no longer valid or the groups associated with the user
have changed, this won't be picked up.

We don't want to cache any "roles". First, the mapping of the Caller to
roles can change from time to time so we don't want to cache that
result. Second, "roles" are not first-class parts of the Authorizer API;
they are used by our standard impls of it, but we want to allow custom
impls that may not care about roles.

> Part 5: Domain Notifications
> ——————————————
>
> Notifications are also intended to work in domain mode. In particular, they will be used to observe server state.
>
> The following notifications will be emitted by resources at /host=XXX/server-config=YYY (i.e. the resource to start/stop/etc. a server):
> * server-started
> * server-stopped
> * server-restarted
> * server-destroyed
> * server-killed
>
> Part 6: Integration with local JMX
> —————————————————
>
> The jmx subsystem will be updated to leverage the WildFly notifications and expose them as MBean notifications in our jmx facade for the management model:
> * the WildFly notification description will be converted to MBeanNotificationInfo and added to the MBeanInfo
> * when a JMX notification listener is added to an ObjectName, a WildFly NotificationHandler will be added to the path address corresponding to the ObjectName.
> * depending on the user feedback, we may provide a hack to convert some WildFly notifications to their well-known JMX equivalent notifications (e.g. resource-added => jmx.mbean.registered).
>
> In a first step, integration will be limited to use of JMX locally. Remoting will not be supported.
>

Everything up to this point I'd like to see in 8.2.

> Part 7: Integration with Remote Management API
> ———————————————————————
>
> We will enhance the remote management native API to register/unregister a notification handler from the ModelControllerClient
>
>      void registerNotificationHandler(ModelNode resourceAddress, NotificationClientHandler handler, NotificationClientFilter filter);
>
> The client contract will have to taken into account reconnection when server is reloaded (possibly by caching the handler & filter and register them again after reconnection to the server...)
>

Last we talked about this we planned to do a new controller client
variant that could better handle this.

> The Management HTTP API will also be enhance to support notifications with its REST API.
> A neat addition will be to provide a browser-specific way to push notifications to the browser (e.g. using Server-Sent Events or Web Sockets).
> => the Web Console is the recipient for this feature and will have their say in how they prefer to consume notifications
>
> Part 8: Integration with Remote JMX
> —————————————————
>
> Once the WildFly Management API will support notifications (for both native and HTTP), we can add support to JMX remotely (if there is any user interest for it).
>
> Part 9: Web Console UX improvement
> —————————————————
>
> Once the Management HTTP API supports notifications, the Web console can leverage it to improve its UX.
>
> This is a task that touch different parts of the app server (mainly in wildfly-core though) and I intend to split it in different JIRA issues (approx. one for each part) that can be merged one after the other instead of a big huge commit.
>
> What do you think?
>

Sounds good.

> jeff
>
>


--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to add notifications to WildFly management model and API

Heiko Braun
In reply to this post by Jeff Mesnil

On 07 Jul 2014, at 16:46, Jeff Mesnil <[hidden email]> wrote:

The description of a notification will be composed of:

* type - String - the type of notification (resource-added, server-stopped, etc.)
* description - String - i18ned description of the notification
* access-constraints - the RBAC access constraints that controls who can receive the notifications
* data-type - ModelType or complex structure - optional - only present if the notification will have a data value. data-type will detail the structure of the data value, enumerating the value's fields and the type of their value


I assume there will be default notification types provided by all resources and specific notifications types that subsystems can introduce? 

How do we get to the supported types that resources can emit? Will there be a textual description, similar to read-resource-description()

Regards, Heiko


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to add notifications to WildFly management model and API

Jeff Mesnil

On 9 Jul 2014, at 09:33, Heiko Braun <[hidden email]> wrote:

>
> On 07 Jul 2014, at 16:46, Jeff Mesnil <[hidden email]> wrote:
>
>> The description of a notification will be composed of:
>>
>> * type - String - the type of notification (resource-added, server-stopped, etc.)
>> * description - String - i18ned description of the notification
>> * access-constraints - the RBAC access constraints that controls who can receive the notifications
>> * data-type - ModelType or complex structure - optional - only present if the notification will have a data value. data-type will detail the structure of the data value, enumerating the value's fields and the type of their value
>
>
> I assume there will be default notification types provided by all resources and specific notifications types that subsystems can introduce?

Yes, default notification types provided by all resources are described in Part 3: Global Resource Notifications and would be resource-added, resource-removed and attribute-value-written.

Specific notification types can then be introduced by any resource. For example, in domain mode, the /host=X/server-config=Y resource will emit notifications for server lifecycle (started, stopped, killed, etc.) as described in Part 5: Domain Notifications.

Once the notification support is put into WildFy core, subsystems would be able to leverage them. For example, I plan to add a notification in the messaging subsystem when failover occurs and a backup server becomes live.

> How do we get to the supported types that resources can emit? Will there be a textual description, similar to read-resource-description()

The notification types will be put into the read-resource-description operation as described in Part 1: Notification Definition.
A management client would be able to know which notifications can be emitted by the resource by calling :read-resource-description(notifications=true).
The notification definition has a i18ned description attribute that is human-readable.

In my current prototype, I have a design issue because a resource can emit a notification without having a corresponding notification definition in its description. I’m not sure if that is a significant issue. If a resource emits a notification without describing it, it would not help clients discover that it is emitted. On the other hand, if I want to enforce that, I can only do it when the notification is emitted at runtime and I am not sure it is a good idea (the server would boot fine and only when the code is run, it would become apparent the resource is incorrectly defined…). I am still pondering what is the best way to handle this but ideally I want the resource description to be consistent with the notifications that are effectively emitted by the resource.

jeff

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


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to add notifications to WildFly management model and API

Jeff Mesnil
In reply to this post by Brian Stansberry

On 8 Jul 2014, at 23:07, Brian Stansberry <[hidden email]> wrote:

> On 7/7/14, 9:46 AM, Jeff Mesnil wrote:
>> # Add Notification support to WildFly Management
>>
>> Tracked by https://issues.jboss.org/browse/WFLY-266
>>
>> Use Cases
>> ---------
>>
>> Notifications are an useful mechanism to observe management changes on WildFly servers.
>> It allows an administrator to be informed of changes outside of his own actions (e.g. a server has been killed, a new application is deployed, etc.)
>>
>> Currently WildFly lacks notifications and users that were depending on JMX notifications in previous versions have no similar feature to use.
>>
>> The most expected use cases for WildFly notifications are:
>> - enhance UX for Web console. Using notifications, the Web console could notify the users of changes outside its own actions.
>> - replacement for JMX notifications. Users that were listening for JMX notifications to observe management changes would have a similar feature using WildFly own notifications
>> - integration with JMX. Notifications emitted by WildFly could be converted and made available using JMX notifications (including notifications for mbean registered/unregistered)
>>
>> Part 1: Notification Definition
>> -------------------------------
>>
>> A resource will define the notifications it emits. These definitions will be added to the attributes and operations definitions on a resource.
>>
>>       {
>>  "description" => "A manageable resource",
>>           "attributes" => {
>>     ...
>>           },
>>  "operations" => {
>>     ...
>>           },
>>  "notifications" => {
>>     "resource-added" => {
>>        ...
>>     }
>>  },
>>  "children" => {
>>     ...
>>           }
>>        }
>>
>> The description of a notification will be composed of:
>>
>> * type - String - the type of notification (resource-added, server-stopped, etc.)
>> * description - String - i18ned description of the notification
>> * access-constraints - the RBAC access constraints that controls who can receive the notifications
>> * data-type - ModelType or complex structure - optional - only present if the notification will have a data value. data-type will detail the structure of the data value, enumerating the value's fields and the type of their value
>>
>> The read-resource-description will be enhanced with a notifications parameter (boolean) to include the notifications descriptions (default value is false, same as the operations parameter).
>>
>> The ManagementResourceRegistration interface will be enhanced to register a notification definition with registerNotification(NotificationDefinition notification). The NotificationDefinition interface corresponds to the detyped representation of a notifications and comes with a builder API.
>>
>> Part 2: Emitting a notification
>> -------------------------------
>>
>> A notification can be emitted in any OperationStepHandler using the OperationContext.emit(Notification method)
>>
>>     public void execute(OperationContext context, ModelNode operation) throws OperationFailedException {
>>
>>        // perform some actions
>>        ...
>>
>>        context.emit(new Notification(SERVER_RESTARTED_NOTIFICATION, address, ROOT_LOGGER.serverHasBeenRestarted()));
>>        context.stepCompleted();
>>     }
>>
>> The notification is *not* emitted (i.e. delivered to interested parties) when OperationContext.emit() is called. It is emitted at the end of the operation step only if it is successful. A call to OperationContext.emit() will have no effect if the operation is rolled back.
>
> To clarify: I believe your intent was delivery is at the end of the
> overall operation execution, when it commits, not at the end of the
> "operation step". I mention this because an operation execution can
> consist of many steps, with even a basic write involving 2 or 3.

You are right, my description was not correct. The notifications are all emitted at the end of the overall operation execution after it commits.
Either all notifications are emitted or none are.

>
>> Notification emission is done asynchronously using the server thread pool and does not block the execution of the operation that triggered the notification: having zero or any notification handlers must have no impact of the execution of the operation.
>>
>> A Notification is a simple Java class that represents the notification. It is composed of:
>>
>> * type - String - the notification type
>> * address - PathAddress - the address of the resource that emits the notification
>> * message - String - the i18ned description of the message
>> * timestamp - long - the timestamp of the notification. It is set when the Notification object is created.
>> * data - ModelNode - optional - a detyped representation of data associated to the notification. If a notification includes a data field, its definition must describe it (in its data-type parameter).
>>
>> If RBAC is enabled, the notification access-constraints will be checked to ensure that the handler have the required privileges to receive the notification. Notification will potentially contain critical information (e.g. if a security-credential attribute is updated, the notification will contain its old and new values) and must be constrained accordingly.
>>
>
> We also need to use SecurityManager permissions around the handler
> registration. Non-remote registrations basically get all permissions,
> same as internal management clients like the deployment-scanner do. We
> control the ability of internal management clients like the scanner to
> create a ModelControllerClient using SecurityManager permissions.
>
>> Part 3: Global Resource Notifications
>> ——————————————————
>>
>> In the same way that some operations are available for any resource (e.g. add, remove, read-resource-description), some notifications will be added to any resource of WildFly management model:
>>
>> * resource-added - when a resource is added, it emits a resource-added notification
>> * resource-removed - when a resource is removed, it emits a resource-removed notification
>> * attribute-value-written - when a write-attribute operation is performed successfully on a resource, it emits a attribute-value-written    notification. The notification's data field contains the following information:
>>   * name - String - the name of the attribute
>>   * old-value - the detyped representation of the previous value of the attribute
>>   * new-value - the detyped representation of the new value
>>
>
>>
>> Part 4: Notification Handlers
>> ——————————————
>>
>> Any interested parties can receive notifications by registering a NotificationHandler using the ModelController.getNotificationSupport().registerNotificationHandler(source, handler, filter) method.
>>
>> The source is a path address to handle notifications emitted by resources at this address.
>> The NotificationHandler is an interface with a single handleNotification(Notification notification) method.
>> The isNotificationEnabled(Notification notification) is an interface with a single isNotificationEnabled(Notification notification) method to filter out uninteresting notifications.
>>
>> There is a similar unregister method to unregister a (handler, filter)
>>
>> To be useful, the source path address will have to accept wildcards for the address' values:
>> * /subsystem=messaging/hornetq-server=* to receive notifications emitted by any hornetq-server resources
>> * /subsystem=messaging/hornetq-server=*/jms-queue=* to receive notifications emitted by any jms-queue on any hornetq-server resources
>>
>> Wildcards for address' keys or key/value paris are not allowed (/subsystem=messaging/*=*/jms-queue=* and /subsystem=messaging/*/jms-queue=* are not valid).
>>
>> This notion of wildcard for the resource addresses should be made to match current usage (e.g. in the CLI).
>>
>> The main reason for the wildcard is for the resource-added/resource-removed notifications. I find more intuitive to have the notifications at the same resource-level than their corresponding add/remove operations.
>
> Agreed. I don't think this should be an issue. We shouldn't use the
> Resource tree anyway as the data structure for retaining the registered
> handlers; a separate structure is needed. The wildcards are fine as long
> as there's a relevant ManagementResourceRegistration.

In my POC, I am using a single Map to retain the handler and is separate from the resource tree.
The Map keys are the path address from the registerNotificationHandler() method (that can be wildcard addresses).
When a notification is emitted, I iterate on its entries to find the handlers that match the actual address of resource emitting the notification.
I.e. the data structure grows with the number of handlers, not with the resources that emits notifications.

>> However until the resource is created, there is no way to register a notification listener on it without using a wildcard.
>> If that proves problematic, we could change this approach with two alternatives:
>> * have a single well-known resource emit the notifications for all resource (that's the JMX approach). A likely candidate would be /core-service=management
>> * the resource-added/-removed notifications can be emitted by the resource parents (but it only fixes the issue for the last leaf of the address tree…)
>>
>> I still have questions about RBAC enforcements and it is possible that the registration of a handler will have to be done with additional metadata identifying the user roles wrt RBAC...
>>
>
> It's not critical until you get to Part 7 but we'll need to sort it out
> before even starting on Part 7.
>
> The user-related inputs into the existing RBAC logic (see
> org.jboss.as.controller.access.Authorizer) are the Caller and
> Environment. The Caller basically just wraps a Subject, exposing the
> data from the relevant Principal types (name and groups).
>
> We could just cache the Caller in effect when the handler is registered
> and use it for authorizing delivery of each notification. The problem is
> if the user if no longer valid or the groups associated with the user
> have changed, this won't be picked up.
>
> We don't want to cache any "roles". First, the mapping of the Caller to
> roles can change from time to time so we don't want to cache that
> result. Second, "roles" are not first-class parts of the Authorizer API;
> they are used by our standard impls of it, but we want to allow custom
> impls that may not care about roles.
>
>> Part 5: Domain Notifications
>> ——————————————
>>
>> Notifications are also intended to work in domain mode. In particular, they will be used to observe server state.
>>
>> The following notifications will be emitted by resources at /host=XXX/server-config=YYY (i.e. the resource to start/stop/etc. a server):
>> * server-started
>> * server-stopped
>> * server-restarted
>> * server-destroyed
>> * server-killed
>>
>> Part 6: Integration with local JMX
>> —————————————————
>>
>> The jmx subsystem will be updated to leverage the WildFly notifications and expose them as MBean notifications in our jmx facade for the management model:
>> * the WildFly notification description will be converted to MBeanNotificationInfo and added to the MBeanInfo
>> * when a JMX notification listener is added to an ObjectName, a WildFly NotificationHandler will be added to the path address corresponding to the ObjectName.
>> * depending on the user feedback, we may provide a hack to convert some WildFly notifications to their well-known JMX equivalent notifications (e.g. resource-added => jmx.mbean.registered).
>>
>> In a first step, integration will be limited to use of JMX locally. Remoting will not be supported.
>>
>
> Everything up to this point I'd like to see in 8.2.

I have create JIRA issues for the parts (as dependencies of the umbrella issue http://issues.jboss.org//browse/WFLY-266) and set their fix versions for both 8.2.0.CR1 and 9.0.0.Alpha1.

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


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to add notifications to WildFly management model and API

kkhan
In reply to this post by Jeff Mesnil

On 10 Jul 2014, at 10:41, Jeff Mesnil <[hidden email]> wrote:

>
> On 9 Jul 2014, at 09:33, Heiko Braun <[hidden email]> wrote:
>
>>
>> On 07 Jul 2014, at 16:46, Jeff Mesnil <[hidden email]> wrote:
>>
>>> The description of a notification will be composed of:
>>>
>>> * type - String - the type of notification (resource-added, server-stopped, etc.)
>>> * description - String - i18ned description of the notification
>>> * access-constraints - the RBAC access constraints that controls who can receive the notifications
>>> * data-type - ModelType or complex structure - optional - only present if the notification will have a data value. data-type will detail the structure of the data value, enumerating the value's fields and the type of their value
>>
>>
>> I assume there will be default notification types provided by all resources and specific notifications types that subsystems can introduce?
>
> Yes, default notification types provided by all resources are described in Part 3: Global Resource Notifications and would be resource-added, resource-removed and attribute-value-written.
>
> Specific notification types can then be introduced by any resource. For example, in domain mode, the /host=X/server-config=Y resource will emit notifications for server lifecycle (started, stopped, killed, etc.) as described in Part 5: Domain Notifications.
>
> Once the notification support is put into WildFy core, subsystems would be able to leverage them. For example, I plan to add a notification in the messaging subsystem when failover occurs and a backup server becomes live.
>
>> How do we get to the supported types that resources can emit? Will there be a textual description, similar to read-resource-description()
>
> The notification types will be put into the read-resource-description operation as described in Part 1: Notification Definition.
> A management client would be able to know which notifications can be emitted by the resource by calling :read-resource-description(notifications=true).
> The notification definition has a i18ned description attribute that is human-readable.
>
> In my current prototype, I have a design issue because a resource can emit a notification without having a corresponding notification definition in its description. I’m not sure if that is a significant issue. If a resource emits a notification without describing it, it would not help clients discover that it is emitted. On the other hand, if I want to enforce that, I can only do it when the notification is emitted at runtime and I am not sure it is a good idea (the server would boot fine and only when the code is run, it would become apparent the resource is incorrectly defined…). I am still pondering what is the best way to handle this but ideally I want the resource description to be consistent with the notifications that are effectively emitted by the resource.
Not enforcing, a big fat warning if not defined, and some asserts to pick this up during testing when assertions are enabled could be a happy middle ground. We can probably add some notification testing to model-/subsystem-/core-model-test as well.

>
> jeff
>
> --
> Jeff Mesnil
> JBoss, a division of Red Hat
> http://jmesnil.net/
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to add notifications to WildFly management model and API

Jeff Mesnil
In reply to this post by Jeff Mesnil

On 07 Jul 2014, at 16:46, Jeff Mesnil <[hidden email]> wrote:

> # Add Notification support to WildFly Management
>
> Tracked by https://issues.jboss.org/browse/WFLY-266
>
> Part 1: Notification Definition
> Part 2: Emitting a notification
> Part 4: Notification Handlers

=> The 3 parts were done in WFLY-266[1]

> Part 3: Global Resource Notifications

=> done in WFLY-3603[2]

> Part 5: Domain Notifications

=> code to emit notifications in domain mode is trivial[3] but I can’t test it out since there is no current way to connect to the DC and listen for notifications. I will defer this after we add notification support for our remote controller API (or if someone has a compelling use case to use these notifications from inside the DC).

So far, we have in master branch all we wanted to put in 8.2 and I’ll backport it.

> Part 6: Integration with local JMX

For this part, we only want to enable local JMX notifications.
This would allow to use JMX notifications from WildFly through access of its MBeanServerService only.

* Using in-vm ManagementFactory.getPlatformMBeanServer() does *not* work (WildFly facade MBeans are not registered in this MBean server)
* Using remote connection via the Attach API does *not* work (e.g. when you connect using jconsole/jvisualvm from the same machine)
* Using remote connection via our remoting-jmx connector does *not* work

We first need to support RBAC and support notifications from our own remote management API (native + HTTP) before allowing it for JMX.

As it stands now, the integration in JMX is quite limited as only subsystems can access them.

Another thing I’m still considering is how much idiomatic the JMX integration should be. At the moment, the conversion from WildFly notifications to JMX is straightforward.
* when a resource is added/removed, the notification is emitted at at is location in the resource trees
  => in JMX, registering/unregistering a MBean emits notifications at a single location in the JMImplementation:type=MBeanServerDelegate
  => Users wanted to capture our facade means notifications would have to register their listener against the jboss.as:* ObjectName pattern instead
* when an attribute changes, the type of the JMX notification remains attribute-value-written
  => Does it make sense to convert that to JMX AttributeChangeNotification?
* A more specific question would be about jconsole/jvisualvm support? As an example: if a resource is added to WildFly, jconsole UI tree will not be refreshed to display the new MBean since it listens to notifications on the JMImplementation:type=MBeanServerDelegate for that.

I’m about to submit the PR to add local JMX notification to WildFly but I wanted to make sure we agree on the scope of the JMX integration.
Preventing notifications from remote connections makes from some ugly code (as JMX is designed to not care if the MBean server connection is local or remote) but it is important we do not “leak” notifications to the outside with critical information until we have proper RBAC support for it.

Maybe, I should add RBAC support now and propose a single PR for the local JMX integration and RBAC at the same time.

wdyt?
jeff

[1] http://issues.jboss.org//browse/WFLY-266
[2] https://issues.jboss.org/browse/WFCORE-28
[3] https://github.com/jmesnil/wildfly-core/tree/WFLY-3602_domain_server_notifications

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


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to add notifications to WildFly management model and API

jtgreene
Administrator
In reply to this post by Jeff Mesnil

On Jul 10, 2014, at 4:52 AM, Jeff Mesnil <[hidden email]> wrote:

>
> On 8 Jul 2014, at 23:07, Brian Stansberry <[hidden email]> wrote:
>
>> On 7/7/14, 9:46 AM, Jeff Mesnil wrote:

-snip-

>>> The main reason for the wildcard is for the resource-added/resource-removed notifications. I find more intuitive to have the notifications at the same resource-level than their corresponding add/remove operations.
>>
>> Agreed. I don't think this should be an issue. We shouldn't use the
>> Resource tree anyway as the data structure for retaining the registered
>> handlers; a separate structure is needed. The wildcards are fine as long
>> as there's a relevant ManagementResourceRegistration.
>
> In my POC, I am using a single Map to retain the handler and is separate from the resource tree.
> The Map keys are the path address from the registerNotificationHandler() method (that can be wildcard addresses).
> When a notification is emitted, I iterate on its entries to find the handlers that match the actual address of resource emitting the notification.
> I.e. the data structure grows with the number of handlers, not with the resources that emits notifications.

Is this map broken up into path segments to mitigate the o(n) cost?

e.g.determining if /x=blah/y=foo/z=bar matches x=blah/y=foo/* = 2 O(1) map lookups

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to add notifications to WildFly management model and API

kkhan
In reply to this post by Jeff Mesnil

On 4 Aug 2014, at 14:51, Jeff Mesnil <[hidden email]> wrote:

>
> On 07 Jul 2014, at 16:46, Jeff Mesnil <[hidden email]> wrote:
>
>> # Add Notification support to WildFly Management
>>
>> Tracked by https://issues.jboss.org/browse/WFLY-266
>>
>> Part 1: Notification Definition
>> Part 2: Emitting a notification
>> Part 4: Notification Handlers
>
> => The 3 parts were done in WFLY-266[1]
>
>> Part 3: Global Resource Notifications
>
> => done in WFLY-3603[2]
>
>> Part 5: Domain Notifications
>
> => code to emit notifications in domain mode is trivial[3] but I can’t test it out since there is no current way to connect to the DC and listen for notifications. I will defer this after we add notification support for our remote controller API (or if someone has a compelling use case to use these notifications from inside the DC).
>
> So far, we have in master branch all we wanted to put in 8.2 and I’ll backport it.
>
>> Part 6: Integration with local JMX
>
> For this part, we only want to enable local JMX notifications.
> This would allow to use JMX notifications from WildFly through access of its MBeanServerService only.
>
> * Using in-vm ManagementFactory.getPlatformMBeanServer() does *not* work (WildFly facade MBeans are not registered in this MBean server)
If that is true, that is a bug - we put some hooks into JBoss Modules ages ago to make the pluggable mbean server the platform mbean server. Are you seeing this in wildfly-core or wildfly?

> * Using remote connection via the Attach API does *not* work (e.g. when you connect using jconsole/jvisualvm from the same machine)
> * Using remote connection via our remoting-jmx connector does *not* work
>
> We first need to support RBAC and support notifications from our own remote management API (native + HTTP) before allowing it for JMX.
>
> As it stands now, the integration in JMX is quite limited as only subsystems can access them.
>
> Another thing I’m still considering is how much idiomatic the JMX integration should be. At the moment, the conversion from WildFly notifications to JMX is straightforward.
> * when a resource is added/removed, the notification is emitted at at is location in the resource trees
>  => in JMX, registering/unregistering a MBean emits notifications at a single location in the JMImplementation:type=MBeanServerDelegate
>  => Users wanted to capture our facade means notifications would have to register their listener against the jboss.as:* ObjectName pattern instead
> * when an attribute changes, the type of the JMX notification remains attribute-value-written
>  => Does it make sense to convert that to JMX AttributeChangeNotification?
> * A more specific question would be about jconsole/jvisualvm support? As an example: if a resource is added to WildFly, jconsole UI tree will not be refreshed to display the new MBean since it listens to notifications on the JMImplementation:type=MBeanServerDelegate for that.
>
> I’m about to submit the PR to add local JMX notification to WildFly but I wanted to make sure we agree on the scope of the JMX integration.
> Preventing notifications from remote connections makes from some ugly code (as JMX is designed to not care if the MBean server connection is local or remote) but it is important we do not “leak” notifications to the outside with critical information until we have proper RBAC support for it.
>
> Maybe, I should add RBAC support now and propose a single PR for the local JMX integration and RBAC at the same time.
>
> wdyt?
> jeff
>
> [1] http://issues.jboss.org//browse/WFLY-266
> [2] https://issues.jboss.org/browse/WFCORE-28
> [3] https://github.com/jmesnil/wildfly-core/tree/WFLY-3602_domain_server_notifications
>
> --
> Jeff Mesnil
> JBoss, a division of Red Hat
> http://jmesnil.net/
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to add notifications to WildFly management model and API

Jeff Mesnil

On 04 Aug 2014, at 16:40, Kabir Khan <[hidden email]> wrote:
>>> Part 6: Integration with local JMX
>>
>> For this part, we only want to enable local JMX notifications.
>> This would allow to use JMX notifications from WildFly through access of its MBeanServerService only.
>>
>> * Using in-vm ManagementFactory.getPlatformMBeanServer() does *not* work (WildFly facade MBeans are not registered in this MBean server)
> If that is true, that is a bug - we put some hooks into JBoss Modules ages ago to make the pluggable mbean server the platform mbean server. Are you seeing this in wildfly-core or wildfly?

You’re correct: the ManagementFactory.getPlatformMBeanServer() is our pluggable mbean server (I’ve been tricked by the tests that does not make the MBeanServerBuilder thingie).

So our notifications can be used by JMX client through the ManagementFactory.getPlatformMBeanServer() too.

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


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to add notifications to WildFly management model and API

Brian Stansberry
In reply to this post by Jeff Mesnil
On 8/4/14, 8:51 AM, Jeff Mesnil wrote:

>
> On 07 Jul 2014, at 16:46, Jeff Mesnil <[hidden email]> wrote:
>
>> # Add Notification support to WildFly Management
>>
>> Tracked by https://issues.jboss.org/browse/WFLY-266
>>
>> Part 1: Notification Definition
>> Part 2: Emitting a notification
>> Part 4: Notification Handlers
>
> => The 3 parts were done in WFLY-266[1]
>
>> Part 3: Global Resource Notifications
>
> => done in WFLY-3603[2]
>
>> Part 5: Domain Notifications
>
> => code to emit notifications in domain mode is trivial[3] but I can’t test it out since there is no current way to connect to the DC and listen for notifications. I will defer this after we add notification support for our remote controller API (or if someone has a compelling use case to use these notifications from inside the DC).
>
> So far, we have in master branch all we wanted to put in 8.2 and I’ll backport it.
>
>> Part 6: Integration with local JMX
>
> For this part, we only want to enable local JMX notifications.
> This would allow to use JMX notifications from WildFly through access of its MBeanServerService only.
>
> * Using in-vm ManagementFactory.getPlatformMBeanServer() does *not* work (WildFly facade MBeans are not registered in this MBean server)
> * Using remote connection via the Attach API does *not* work (e.g. when you connect using jconsole/jvisualvm from the same machine)
> * Using remote connection via our remoting-jmx connector does *not* work
>
> We first need to support RBAC and support notifications from our own remote management API (native + HTTP) before allowing it for JMX.
>
> As it stands now, the integration in JMX is quite limited as only subsystems can access them.
>
> Another thing I’m still considering is how much idiomatic the JMX integration should be. At the moment, the conversion from WildFly notifications to JMX is straightforward.
> * when a resource is added/removed, the notification is emitted at at is location in the resource trees
>    => in JMX, registering/unregistering a MBean emits notifications at a single location in the JMImplementation:type=MBeanServerDelegate
>    => Users wanted to capture our facade means notifications would have to register their listener against the jboss.as:* ObjectName pattern instead

Are you saying the standard MBeanServerNotification via
JMImplementation:type=MBeanServerDelegate wouldn't work? I think it should.

> * when an attribute changes, the type of the JMX notification remains attribute-value-written
>    => Does it make sense to convert that to JMX AttributeChangeNotification?

That seems like the intuitive thing to do, and anyone trying to use JMX
to monitor the system would expect such notifications. Why wouldn't we
do that?

> * A more specific question would be about jconsole/jvisualvm support? As an example: if a resource is added to WildFly, jconsole UI tree will not be refreshed to display the new MBean since it listens to notifications on the JMImplementation:type=MBeanServerDelegate for that.
>
> I’m about to submit the PR to add local JMX notification to WildFly but I wanted to make sure we agree on the scope of the JMX integration.
> Preventing notifications from remote connections makes from some ugly code (as JMX is designed to not care if the MBean server connection is local or remote) but it is important we do not “leak” notifications to the outside with critical information until we have proper RBAC support for it.
>
> Maybe, I should add RBAC support now and propose a single PR for the local JMX integration and RBAC at the same time.
>

How complex would the RBAC support be? I'm reluctant to try for
something in any way complex at this stage.

> wdyt?
> jeff
>
> [1] http://issues.jboss.org//browse/WFLY-266
> [2] https://issues.jboss.org/browse/WFCORE-28
> [3] https://github.com/jmesnil/wildfly-core/tree/WFLY-3602_domain_server_notifications
>


--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to add notifications to WildFly management model and API

Jeff Mesnil
In reply to this post by jtgreene

On 04 Aug 2014, at 16:27, Jason Greene <[hidden email]> wrote:
 POC, I am using a single Map to retain the handler and is separate from the resource tree.
>> The Map keys are the path address from the registerNotificationHandler() method (that can be wildcard addresses).
>> When a notification is emitted, I iterate on its entries to find the handlers that match the actual address of resource emitting the notification.
>> I.e. the data structure grows with the number of handlers, not with the resources that emits notifications.
>
> Is this map broken up into path segments to mitigate the o(n) cost?
>
> e.g.determining if /x=blah/y=foo/z=bar matches x=blah/y=foo/* = 2 O(1) map lookups

This is definitely something I need to do to decrease the lookup cost.
I’ll have a look if I can reuse the code from our resource registry for that.

thanks,
jeff

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


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to add notifications to WildFly management model and API

Jeff Mesnil
In reply to this post by Brian Stansberry

On 04 Aug 2014, at 21:36, Brian Stansberry <[hidden email]> wrote:

>> Another thing I’m still considering is how much idiomatic the JMX integration should be. At the moment, the conversion from WildFly notifications to JMX is straightforward.
>> * when a resource is added/removed, the notification is emitted at at is location in the resource trees
>>   => in JMX, registering/unregistering a MBean emits notifications at a single location in the JMImplementation:type=MBeanServerDelegate
>>   => Users wanted to capture our facade means notifications would have to register their listener against the jboss.as:* ObjectName pattern instead
>
> Are you saying the standard MBeanServerNotification via
> JMImplementation:type=MBeanServerDelegate wouldn't work? I think it should.
>
>> * when an attribute changes, the type of the JMX notification remains attribute-value-written
>>   => Does it make sense to convert that to JMX AttributeChangeNotification?
>
> That seems like the intuitive thing to do, and anyone trying to use JMX
> to monitor the system would expect such notifications. Why wouldn't we
> do that?

As a followup, I’ve submitted a PR for the local JMX notifications with your suggestion:
* resource-added/removed are converted to MBeanServerNotification emitted by JMImplementation:type=MBeanServerDelegate
* attribute-value-written are converted to AttributeChangeNotifcation emitted by the resource itself.

jeff

[1] https://github.com/wildfly/wildfly-core/pull/82
--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to add notifications to WildFly management model and API

Heiko W.Rupp
In reply to this post by Brian Stansberry

Am 04.08.2014 um 21:36 schrieb Brian Stansberry <[hidden email]>:
>> * when an attribute changes, the type of the JMX notification remains attribute-value-written
>>   => Does it make sense to convert that to JMX AttributeChangeNotification?
>
> That seems like the intuitive thing to do, and anyone trying to use JMX
> to monitor the system would expect such notifications. Why wouldn't we
> do that?


+1

There is so much tooling for JMX available that this should be treated as  a first class citizen.


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to add notifications to WildFly management model and API

weedfly
In reply to this post by Jeff Mesnil
Hi guys

Can you please tell me if the support for notifications is embedded in wildfly 81.0-Final ?*
I'm migrating an ear from 4.3EAP to wildfly and my application relies on startup stop jmx notifications to start some treatments.
As a result, my application does not run correctly because of the absence of this feature.

Could you please suggest me an alternative supplied by widfly to solve my problem ?

thank you
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to add notifications to WildFly management model and API

Jeff Mesnil
Support for WildFly notifications has been backported to 8.2.0.CR1.
It is not in 8.1.0.Final.

jeff

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

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to add notifications to WildFly management model and API

weedfly
Thank you for the quick response.
I know it is not the right place to talk about it but where can i find this version ? It did not appears on download section of the website ?

Best regards

Reply | Threaded
Open this post in threaded view
|

Re: Proposal to add notifications to WildFly management model and API

Tomaž Cerar-2
In reply to this post by Jeff Mesnil
On github. Branch 8.x.
It is not released yet.

But you can try with 9.0.0.Alpha1 which also has notifications.



Sent from my PhoneFrom: weedfly
Sent: ‎20.‎10.‎2014 16:23
To: [hidden email]
Subject: Re: [wildfly-dev] Proposal to add notifications to WildFly
management model and API
Thank you for the quick response.
I know it is not the right place to talk about it but where can i find this
version ? It did not appears on download section of the website ?

Best regards





--
View this message in context:
http://wildfly-development.1055759.n5.nabble.com/Proposal-to-add-notifications-to-WildFly-management-model-and-API-tp5714484p5715143.html
Sent from the WildFly Development mailing list archive at Nabble.com.
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to add notifications to WildFly management model and API

weedfly
Oki,

I tried with 9.0.0.Alpha1 but i receive only one notification (jmx attribute change) and not the start / stop notifications.

I register my listener this way:

   final ObjectName webServerName = ObjectName.getInstance("jboss.web:service=WebServer");
                    LOGGER.debug("Enregistrement du listener pour le mbean jboss.web:service=WebServer");
                    mBeanserver.addNotificationListener(webServerName, this, null, null);
                    LOGGER.debug("Récupération du mbean jboss.system:type=Server");
                    final ObjectName serverName = ObjectName.getInstance("jboss.system:type=Server");
                    LOGGER.debug("Enregistrement du listener pour le mbean jboss.system:type=Server");
                    mBeanserver.addNotificationListener(serverName, this, null, null);
                    LOGGER.info("Fin de l'initialisation du listener");

Is it still the way to do it or do wildfly supply a new API to register listeners ?

Thank you for your help.