Add Notification support to the domain management API

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

Add Notification support to the domain management API

Jeff Mesnil
I've started to work on  [AS7-370] Add Notification support to the domain management API[1].

To make sure we agree on the content and scope of this task, I've created a doc on our dev forum summarizing what I intend to do (and not do) about this[2].
It's a simple draft but I'd appreciate any feedback on this.
I'm particularly interested by the use cases what would benefit from such notifications (Web Console, auditing, others…) to make sure they'd be covered by the requirements.

I'm trying to keep this as simple as possible for subsystems to leverage notifications without too much involvement while making sure there are no performance or memory penalty for the AS7 to handle them.

jeff

[1] https://issues.jboss.org/browse/AS7-370
[2] https://community.jboss.org/wiki/AddNotificationSupportToTheDomainManagementAPI
--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/


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

Re: Add Notification support to the domain management API

Brian Stansberry
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?

2) Support for remote notifications is important. Perhaps more value in
this than in a generic internal mechanism. The notification mechanism
becomes an standard means via which changes internal to the server (or
group of servers) can be communicated to management tools.

In a domain, a host has joined/left. A server has been started stopped.
Cluster topology changes at the JGroups or Infinispan levels.

3) I can see making use of the facilities for 2) in the domain
management layer itself. For example, the DOMAIN_PING request (JGroups
discovery protocol based on asking the domain for information on
available peers) could use management notifications to propagate the
necessary data.

On 2/14/13 11:06 AM, Jeff Mesnil wrote:

> I've started to work on  [AS7-370] Add Notification support to the domain management API[1].
>
> To make sure we agree on the content and scope of this task, I've created a doc on our dev forum summarizing what I intend to do (and not do) about this[2].
> It's a simple draft but I'd appreciate any feedback on this.
> I'm particularly interested by the use cases what would benefit from such notifications (Web Console, auditing, others…) to make sure they'd be covered by the requirements.
>
> I'm trying to keep this as simple as possible for subsystems to leverage notifications without too much involvement while making sure there are no performance or memory penalty for the AS7 to handle them.
>
> jeff
>
> [1] https://issues.jboss.org/browse/AS7-370
> [2] https://community.jboss.org/wiki/AddNotificationSupportToTheDomainManagementAPI
>


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

Re: Add Notification support to the domain management API

Heiko Braun


+1

This is one of main challenges we are facing today. Simple things like restarting servers require a lot of polling. If we can get away from it, the  user experience and consistency of the client applications will greatly improve. 

On Feb 14, 2013, at 11:42 PM, Brian Stansberry <[hidden email]> wrote:

2) Support for remote notifications is important. Perhaps more value in 
this than in a generic internal mechanism. The notification mechanism 
becomes an standard means via which changes internal to the server (or 
group of servers) can be communicated to management tools.


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

Re: Add Notification support to the domain management API

Heiko Braun
In reply to this post by Jeff Mesnil
Referring to [2]

You write "The notifications are a feature internal to AS7 and are not meant to be available remotely." 

You mean it's not going to part of the work you are doing, right? Nevertheless any protocol implementation used for remote notifications should be able to interface with the management layer. For instance a web socket layer interfacing the management layer which adopts the notification protocol to HTTP.

An alternative would be build it right into the Java and HTTP protocol we have. But I can see benefits and drawbacks in both approaches. The later is not strictly necessary. I.e. we might have a custom subsystem, able to translate internal notifications to web socket events. Interfacing the notification API. This would decouple the wire protocol from the management layer and the notification API it exposes. 

[wire protocol, i.e. web sockets]
               |
[notification API]
               |
[management layer]

Just food for thought. 


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

Re: Add Notification support to the domain management API

Jeff Mesnil
In reply to this post by Brian Stansberry

Le 14 févr. 2013 à 23:42, Brian Stansberry <[hidden email]> 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.

jeff

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


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

Re: Add Notification support to the domain management API

Jeff Mesnil
In reply to this post by Heiko Braun

Le 15 févr. 2013 à 10:21, Heiko Braun <[hidden email]> a écrit :

> Referring to [2]
>
> You write "The notifications are a feature internal to AS7 and are not meant to be available remotely."
>
> You mean it's not going to part of the work you are doing, right? Nevertheless any protocol implementation used for remote notifications should be able to interface with the management layer. For instance a web socket layer interfacing the management layer which adopts the notification protocol to HTTP.
>
> An alternative would be build it right into the Java and HTTP protocol we have. But I can see benefits and drawbacks in both approaches. The later is not strictly necessary. I.e. we might have a custom subsystem, able to translate internal notifications to web socket events. Interfacing the notification API. This would decouple the wire protocol from the management layer and the notification API it exposes.
>
> [wire protocol, i.e. web sockets]
>                |
> [notification API]
>                |
> [management layer]
>
> Just food for thought.

At first, I did not want to add remote notifications support to our management API. Clients interested by it (web console, JBoss Tools, etc.) could add subsystems to bridge between the notifications and the transport protocol they can use. That's not a great idea though, we want to provide an uniform & stable way to manage AS7, not let every potential clients puts bits in the server-side to interact with it.

So, let's add the notifications to the management API.

I don't see a big issue to do that with our Java API, we could add a registerNotificationListener(ModelNode, NotificationListener) with the listener being called back when a notification is emitted.

However, I don't have a good idea yet for the HTTP API.
I see 2 types of clients for our HTTP API:
  * web clients that uses HTTP only
  * modern web browsers that can leverage Web Sockets

For the Web console (running in a Web browser), using the Web Sockets protocol seems a natural fit to handle notifications but that support web sockets protocol from AS7 management service (not sure if it's already in the pipeline).
For plain-HTTP, we could also provide a more RESTful API but it'd be up to the clients to poll to check whether there are new notifications to handle. We could use long-polling techniques to push the notifications back to the clients but I don't know if that'd work outside of web browsers…
If you have other ideas, don't hesitate to send me pointers.

jeff





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


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

Re: Add Notification support to the domain management API

Brian Stansberry
In reply to this post by Jeff Mesnil
On 2/15/13 10:36 AM, Jeff Mesnil wrote:

>
> Le 14 févr. 2013 à 23:42, Brian Stansberry <[hidden email]> 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?

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

Re: Add Notification support to the domain management API

kkhan
In reply to this post by Jeff Mesnil
The jmx facade will also need to be extended to support notifications
On 14 Feb 2013, at 17:06, Jeff Mesnil wrote:

> I've started to work on  [AS7-370] Add Notification support to the domain management API[1].
>
> To make sure we agree on the content and scope of this task, I've created a doc on our dev forum summarizing what I intend to do (and not do) about this[2].
> It's a simple draft but I'd appreciate any feedback on this.
> I'm particularly interested by the use cases what would benefit from such notifications (Web Console, auditing, others…) to make sure they'd be covered by the requirements.
>
> I'm trying to keep this as simple as possible for subsystems to leverage notifications without too much involvement while making sure there are no performance or memory penalty for the AS7 to handle them.
>
> jeff
>
> [1] https://issues.jboss.org/browse/AS7-370
> [2] https://community.jboss.org/wiki/AddNotificationSupportToTheDomainManagementAPI
> --
> Jeff Mesnil
> JBoss, a division of Red Hat
> http://jmesnil.net/
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

---------------------------------------
Kabir Khan
Prinicipal Software Engineer
JBoss by Red Hat


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

Re: Add Notification support to the domain management API

Heiko Braun
In reply to this post by Jeff Mesnil
I think this approach makes sense, in terms of coupling. But i let nrian comment on it.

Am 15.02.2013 um 18:00 schrieb Jeff Mesnil <[hidden email]>:

> At first, I did not want to add remote notifications support to our management API. Clients interested by it (web console, JBoss Tools, etc.) could add subsystems to bridge between the notifications and the transport protocol they can use. That's not a great idea though, we want to provide an uniform & stable way to manage AS7, not let every potential clients puts bits in the server-side to interact with it.

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

Re: Add Notification support to the domain management API

Heiko W.Rupp
In reply to this post by Jeff Mesnil

Am 15.02.2013 um 18:00 schrieb Jeff Mesnil:
> At first, I did not want to add remote notifications support to our management API. Clients interested by it (web console, JBoss Tools, etc.) could add subsystems to bridge between the notifications and the transport protocol they can use. That's not a great idea though, we want to provide an uniform & stable way to manage AS7, not let every potential clients puts bits in the server-side to interact with it.

We need to have one implementation at the api level, that all clients can use. Of course writing internal subsystems is über-cool,
but we should still consider people that want to write their client in e.g. perl.


> However, I don't have a good idea yet for the HTTP API.
> I see 2 types of clients for our HTTP API:
>  * web clients that uses HTTP only
>  * modern web browsers that can leverage Web Sockets
>
> For the Web console (running in a Web browser), using the Web Sockets protocol seems a natural fit to handle notifications but that support web sockets protocol from AS7 management service (not sure if it's already in the pipeline).
> For plain-HTTP, we could also provide a more RESTful API but it'd be up to the clients to poll to check whether there are new notifications to handle. We could use long-polling techniques to push the notifications back to the clients but I don't know if that'd work outside of web browsers…
> If you have other ideas, don't hesitate to send me pointers.

Actually it may be a good first start (even if not "immediate") to just add all the notifications to a list of notifications, that
then get delivered to a client when if connects the next time.

e.g.
:read-resource(bla=fasel)

returns
{
   payload={...}   // real read-resource data
   response-headers={
            notifications=[....]  // queued notifications
}

This partially already exists with the "reload-required"

"response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"
    }

and would just need extending.

returning the list to the client would clear the queue.



_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

signature.asc (210 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Add Notification support to the domain management API

Heiko Braun
I think you are comparing apples and oranges. Providing the subsystem is not a client responsibility and API level is not protocol level (as in wire format) .

The question is if it's beneficial to decouple the client protocol from the core management API or not. But this doesn't mean clients have to provide the subsystem on their own. It's merely a design decision. 

For instance when looking at the HTTP bridge for notifications, it might be beneficial to leverage a subsystem decoupled from the core management layer, that merely acts as an API client to the server internals. This way we might have websocket notifications as an early preview for example.  

If we design it to be a part of the core management layer, then it probably depends on the availability of the undertow components. This is the degree of coupling we could avoid. 

But I don't see all benefits & drawbacks of both approaches yet ...

On Feb 18, 2013, at 9:08 AM, Heiko W.Rupp <[hidden email]> wrote:

We need to have one implementation at the api level, that all clients can use. Of course writing internal subsystems is über-cool,
but we should still consider people that want to write their client in e.g. perl.


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

Re: Add Notification support to the domain management API

Heiko W.Rupp

Am 18.02.2013 um 10:17 schrieb Heiko Braun:

> I think you are comparing apples and oranges. Providing the subsystem is not a client responsibility

I may be, but the latter is exactly what I am saying.

>  and API level is not protocol level (as in wire format) .

As a client to AS7 I care less about the internal implementation and more about how to access the information.
And requiring to set up a websocket "system" in addition to the http endpoint may in some areas just overkill and may reduce
the number of clients that may want to use the notifications.

> For instance when looking at the HTTP bridge for notifications, it might be beneficial to leverage a subsystem decoupled from the core management layer, that merely acts as an API client to the server internals. This way we might have websocket notifications as an early preview for example.  

I am ok with querying another subsystem for notifications instead of piggy backing the information on the
servers reponses - if I can just do that with a HTTP get request.
This may not be as instantaneous as a websocket push, but can be used with existing http-based clients.



_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

signature.asc (210 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Add Notification support to the domain management API

Jeff Mesnil
In reply to this post by Brian Stansberry

Le 15 févr. 2013 à 18:33, Brian Stansberry <[hidden email]> a écrit :

> On 2/15/13 10:36 AM, Jeff Mesnil wrote:
>>
>> Le 14 févr. 2013 à 23:42, Brian Stansberry <[hidden email]> 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/


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

Re: Add Notification support to the domain management API

Brian Stansberry
In reply to this post by Heiko Braun
On 2/18/13 3:17 AM, Heiko Braun wrote:

> I think you are comparing apples and oranges. Providing the subsystem is
> not a client responsibility and API level is not protocol level (as in
> wire format) .
>
> The question is if it's beneficial to decouple the client protocol from
> the core management API or not. But this doesn't mean clients have to
> provide the subsystem on their own. It's merely a design decision.
>
> For instance when looking at the HTTP bridge for notifications, it might
> be beneficial to leverage a subsystem decoupled from the core management
> layer, that merely acts as an API client to the server internals. This
> way we might have websocket notifications as an early preview for example.
>
> If we design it to be a part of the core management layer, then it
> probably depends on the availability of the undertow components. This is
> the degree of coupling we could avoid.
>

Our intent is to switch the HTTP management layer over to undertow.
Hopefully in AS 8. So I don't see a benefit to implementing it using
some other tech in a subsystem. Seems we'd be better off devoting that
energy to making sure the undertow solution gets done.

> But I don't see all benefits & drawbacks of both approaches yet ...
>
> On Feb 18, 2013, at 9:08 AM, Heiko W.Rupp <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>> We need to have one implementation at the api level, that all clients
>> can use. Of course writing internal subsystems is über-cool,
>> but we should still consider people that want to write their client in
>> e.g. perl.
>
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>


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

Re: Add Notification support to the domain management API

Jeff Mesnil
In reply to this post by Heiko W.Rupp
I've updated the doc[1] to focus on the web console use case and the minimal requirements it has.

I wrote a simple plain HTTP API (no WebSockets, working with cURL) that should be enough for the Web console to handle notifications.

Since it's HTTP only, the console would still have to poll but:

1. It will have few well-defined HTTP resources to poll
2. There is an explicit contract for the notifications instead of extracting information from the different responses it get from the server.

This API should be suitable to http-based clients and when undertow is available in AS7, we could provide a WebSocket upgrade on its URL endpoints to push notifications to the browser.

jeff

[1] https://community.jboss.org/wiki/AddNotificationSupportToTheDomainManagementAPI
 
Le 18 févr. 2013 à 11:05, Heiko W.Rupp <[hidden email]> a écrit :

>
> Am 18.02.2013 um 10:17 schrieb Heiko Braun:
>
>> I think you are comparing apples and oranges. Providing the subsystem is not a client responsibility
>
> I may be, but the latter is exactly what I am saying.
>
>> and API level is not protocol level (as in wire format) .
>
> As a client to AS7 I care less about the internal implementation and more about how to access the information.
> And requiring to set up a websocket "system" in addition to the http endpoint may in some areas just overkill and may reduce
> the number of clients that may want to use the notifications.
>
>> For instance when looking at the HTTP bridge for notifications, it might be beneficial to leverage a subsystem decoupled from the core management layer, that merely acts as an API client to the server internals. This way we might have websocket notifications as an early preview for example.  
>
> I am ok with querying another subsystem for notifications instead of piggy backing the information on the
> servers reponses - if I can just do that with a HTTP get request.
> This may not be as instantaneous as a websocket push, but can be used with existing http-based clients.
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

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


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

Re: Add Notification support to the domain management API

Heiko Braun
If we intend to provide support for polling it means the notifications need to be kept in memory. 

- What constraints do apply in this case? (I.e. TTL and MAX notification count?)  
- How does the design of this approach allow us to transition into a push based mechanism?  

Overall I am not sure a poll based solution adds any value to the current architecture. This is what we already do and it doesn't require any interim format, i.e. we directly poll for the existence of server resources. But maybe I am missing something here?

Regards, Heiko


On Feb 22, 2013, at 6:32 PM, Jeff Mesnil <[hidden email]> wrote:

I've updated the doc[1] to focus on the web console use case and the minimal requirements it has.

I wrote a simple plain HTTP API (no WebSockets, working with cURL) that should be enough for the Web console to handle notifications.

Since it's HTTP only, the console would still have to poll but:

1. It will have few well-defined HTTP resources to poll
2. There is an explicit contract for the notifications instead of extracting information from the different responses it get from the server.

This API should be suitable to http-based clients and when undertow is available in AS7, we could provide a WebSocket upgrade on its URL endpoints to push notifications to the browser.

jeff


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

Re: Add Notification support to the domain management API

Darran Lofthouse
In reply to this post by Jeff Mesnil
On 02/22/2013 05:32 PM, Jeff Mesnil wrote:

> I've updated the doc[1] to focus on the web console use case and the minimal requirements it has.
>
> I wrote a simple plain HTTP API (no WebSockets, working with cURL) that should be enough for the Web console to handle notifications.
>
> Since it's HTTP only, the console would still have to poll but:
>
> 1. It will have few well-defined HTTP resources to poll
> 2. There is an explicit contract for the notifications instead of extracting information from the different responses it get from the server.
>
> This API should be suitable to http-based clients and when undertow is available in AS7, we could provide a WebSocket upgrade on its URL endpoints to push notifications to the browser.

A switch to Undertow for domain management is theoretically available soon.

> jeff
>
> [1] https://community.jboss.org/wiki/AddNotificationSupportToTheDomainManagementAPI
>
> Le 18 févr. 2013 à 11:05, Heiko W.Rupp <[hidden email]> a écrit :
>
>>
>> Am 18.02.2013 um 10:17 schrieb Heiko Braun:
>>
>>> I think you are comparing apples and oranges. Providing the subsystem is not a client responsibility
>>
>> I may be, but the latter is exactly what I am saying.
>>
>>> and API level is not protocol level (as in wire format) .
>>
>> As a client to AS7 I care less about the internal implementation and more about how to access the information.
>> And requiring to set up a websocket "system" in addition to the http endpoint may in some areas just overkill and may reduce
>> the number of clients that may want to use the notifications.
>>
>>> For instance when looking at the HTTP bridge for notifications, it might be beneficial to leverage a subsystem decoupled from the core management layer, that merely acts as an API client to the server internals. This way we might have websocket notifications as an early preview for example.
>>
>> I am ok with querying another subsystem for notifications instead of piggy backing the information on the
>> servers reponses - if I can just do that with a HTTP get request.
>> This may not be as instantaneous as a websocket push, but can be used with existing http-based clients.
>>
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Add Notification support to the domain management API

Lukas Krejci
In reply to this post by Heiko Braun
On Monday, February 25, 2013 12:00:11 Heiko Braun wrote:
> If we intend to provide support for polling it means the notifications need
> to be kept in memory.
>
> - What constraints do apply in this case? (I.e. TTL and MAX notification
> count?) - How does the design of this approach allow us to transition into
> a push based mechanism?
>

I may be wrong but I can't see the server creating thousands of notifications
per hour (or even per day). These are notifications about configuration changes
and you don't reconfigure your server every few minutes.

So while TTL and MAX are valid concerns, I don't think it would be a massive
problem to set them both to Integer.MAX_INT.

An interesting, but possibly more complex to implement, would be the
suggestion Heiko R. was saying with "clear the notiification queue once client
reads it". This would possibly require some kind of client registration (so
that mulitple clients can poll for notifs and don't "steal" them from each
other by reading them) and possibly some permanent storage for them to survive
a restart of the server. Essentially notifs would become some kind of config
change journal. But that may be too much.

> Overall I am not sure a poll based solution adds any value to the current
> architecture. This is what we already do and it doesn't require any interim
> format, i.e. we directly poll for the existence of server resources. But
> maybe I am missing something here?
>

One benefit I can see is the reduced load on the server. Instead of flooding the
server with potentially thousands of poll requests (if the client is not
careful and doesn't spread the requests in time), you only poll for the list
of notifications.

> Regards, Heiko
>
> On Feb 22, 2013, at 6:32 PM, Jeff Mesnil <[hidden email]> wrote:
> > I've updated the doc[1] to focus on the web console use case and the
> > minimal requirements it has.
> >
> > I wrote a simple plain HTTP API (no WebSockets, working with cURL) that
> > should be enough for the Web console to handle notifications.
> >
> > Since it's HTTP only, the console would still have to poll but:
> >
> > 1. It will have few well-defined HTTP resources to poll
> > 2. There is an explicit contract for the notifications instead of
> > extracting information from the different responses it get from the
> > server.
> >
> > This API should be suitable to http-based clients and when undertow is
> > available in AS7, we could provide a WebSocket upgrade on its URL
> > endpoints to push notifications to the browser.
> >
> > jeff
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Add Notification support to the domain management API

Heiko Braun

Some additional notification types that admins could make use of:

SERVER_NEEDS_RELOAD
AUTHENTICATION / USER_LOGGED_ON
SYSTEM_IS_GOING_TO_SHUTDOWN
MESSAGE_OF_THE _DAY

I can see the value in these from an administrator point of view. But it raises an interesting question:

Do notification types have different TTL's? (i.e. MOTD)


On Feb 25, 2013, at 2:31 PM, Lukas Krejci <[hidden email]> wrote:

On Monday, February 25, 2013 12:00:11 Heiko Braun wrote:
If we intend to provide support for polling it means the notifications need
to be kept in memory.

- What constraints do apply in this case? (I.e. TTL and MAX notification
count?) - How does the design of this approach allow us to transition into
a push based mechanism?


I may be wrong but I can't see the server creating thousands of notifications
per hour (or even per day). These are notifications about configuration changes
and you don't reconfigure your server every few minutes.

So while TTL and MAX are valid concerns, I don't think it would be a massive
problem to set them both to Integer.MAX_INT.

An interesting, but possibly more complex to implement, would be the
suggestion Heiko R. was saying with "clear the notiification queue once client
reads it". This would possibly require some kind of client registration (so
that mulitple clients can poll for notifs and don't "steal" them from each
other by reading them) and possibly some permanent storage for them to survive
a restart of the server. Essentially notifs would become some kind of config
change journal. But that may be too much.

Overall I am not sure a poll based solution adds any value to the current
architecture. This is what we already do and it doesn't require any interim
format, i.e. we directly poll for the existence of server resources. But
maybe I am missing something here?


One benefit I can see is the reduced load on the server. Instead of flooding the
server with potentially thousands of poll requests (if the client is not
careful and doesn't spread the requests in time), you only poll for the list
of notifications.

Regards, Heiko

On Feb 22, 2013, at 6:32 PM, Jeff Mesnil <[hidden email]> wrote:
I've updated the doc[1] to focus on the web console use case and the
minimal requirements it has.

I wrote a simple plain HTTP API (no WebSockets, working with cURL) that
should be enough for the Web console to handle notifications.

Since it's HTTP only, the console would still have to poll but:

1. It will have few well-defined HTTP resources to poll
2. There is an explicit contract for the notifications instead of
extracting information from the different responses it get from the
server.

This API should be suitable to http-based clients and when undertow is
available in AS7, we could provide a WebSocket upgrade on its URL
endpoints to push notifications to the browser.

jeff
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


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

Re: Add Notification support to the domain management API

Dimitris Andreadis
In reply to this post by Lukas Krejci
I think you should just copy from the JMX model and make the internal/external aspects of
the system completely separate concerns.

E.g the MBeanServer is primarily a JVM constrained local entity, it has a well defined API,
it's almost always synchronous and simple, i.e. no threads, notifications are transmitted
synchronously unless you put a thread pool which rarely happens, etc. So just focus on the
local notifications API, metadata & notification format.

On the other hand, transmitting notifications over the network is way more complex and
dangerous. You have to deal with different protocols, many clients, unreliable clients,
network problems, buffering, queuing per client, aqks, etc. Essentially you need to develop
a mini messaging system in order to do it right. I've seen attempts in the past that started
with the idea that they could just make this part of the model, but they never managed to
implement that properly due to all those complexities.

So it makes total sense to keep this part separate in the form of plugins, like how jsr-160
sits on top of JMX.

/Dimitris

On 25/02/2013 14:31, Lukas Krejci wrote:

> On Monday, February 25, 2013 12:00:11 Heiko Braun wrote:
>> If we intend to provide support for polling it means the notifications need
>> to be kept in memory.
>>
>> - What constraints do apply in this case? (I.e. TTL and MAX notification
>> count?) - How does the design of this approach allow us to transition into
>> a push based mechanism?
>>
>
> I may be wrong but I can't see the server creating thousands of notifications
> per hour (or even per day). These are notifications about configuration changes
> and you don't reconfigure your server every few minutes.
>
> So while TTL and MAX are valid concerns, I don't think it would be a massive
> problem to set them both to Integer.MAX_INT.
>
> An interesting, but possibly more complex to implement, would be the
> suggestion Heiko R. was saying with "clear the notiification queue once client
> reads it". This would possibly require some kind of client registration (so
> that mulitple clients can poll for notifs and don't "steal" them from each
> other by reading them) and possibly some permanent storage for them to survive
> a restart of the server. Essentially notifs would become some kind of config
> change journal. But that may be too much.
>
>> Overall I am not sure a poll based solution adds any value to the current
>> architecture. This is what we already do and it doesn't require any interim
>> format, i.e. we directly poll for the existence of server resources. But
>> maybe I am missing something here?
>>
>
> One benefit I can see is the reduced load on the server. Instead of flooding the
> server with potentially thousands of poll requests (if the client is not
> careful and doesn't spread the requests in time), you only poll for the list
> of notifications.
>
>> Regards, Heiko
>>
>> On Feb 22, 2013, at 6:32 PM, Jeff Mesnil <[hidden email]> wrote:
>>> I've updated the doc[1] to focus on the web console use case and the
>>> minimal requirements it has.
>>>
>>> I wrote a simple plain HTTP API (no WebSockets, working with cURL) that
>>> should be enough for the Web console to handle notifications.
>>>
>>> Since it's HTTP only, the console would still have to poll but:
>>>
>>> 1. It will have few well-defined HTTP resources to poll
>>> 2. There is an explicit contract for the notifications instead of
>>> extracting information from the different responses it get from the
>>> server.
>>>
>>> This API should be suitable to http-based clients and when undertow is
>>> available in AS7, we could provide a WebSocket upgrade on its URL
>>> endpoints to push notifications to the browser.
>>>
>>> jeff
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>

--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Dimitris Andreadis
Software Engineering Manager
JBoss Application Server
by Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx

http://dandreadis.blogspot.com/
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
123