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
|

Re: Add Notification support to the domain management API

Dimitris Andreadis
I haven't seen TTL on Notifications, it looks a bit hard to make something useful from it.

I've only seen notifications that correspond to stateless events (e.g. security violation)
or events that correspond to state full server-side conditions (e.g. memory low)

If you care to read, some older (and forgotten) attempt here:
https://community.jboss.org/wiki/ActiveAlarmTable

On 25/02/2013 17:47, Heiko Braun wrote:

>
> 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] <mailto:[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] <mailto:[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] <mailto:[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
>

--
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
Reply | Threaded
Open this post in threaded view
|

Re: Add Notification support to the domain management API

Heiko Braun
Well, without TTL polling becomes useless, no?

I am not advocating for TTL, but I think it needs to be considered if follow the current design, which is based on polling.
We do probably end up with completely different design if we design for real notifications that make use of asynchronous callbacks. 

 
On Feb 26, 2013, at 11:56 AM, Dimitris Andreadis <[hidden email]> wrote:

I haven't seen TTL on Notifications, it looks a bit hard to make something useful from 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

Dimitris Andreadis
I guess I wanted to say it's hard to estimate TTL in the first place. Or do you propose this
is a function of the notification subsystem itself (how long the notification will be
available/queued) and not the producer of the notification who has context how long the
notification makes sense?

On 26/02/2013 12:30, Heiko Braun wrote:

> Well, without TTL polling becomes useless, no?
>
> I am not advocating for TTL, but I think it needs to be considered if follow the current
> design, which is based on polling.
> We do probably end up with completely different design if we design for real notifications
> that make use of asynchronous callbacks.
>
>
> On Feb 26, 2013, at 11:56 AM, Dimitris Andreadis <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>> I haven't seen TTL on Notifications, it looks a bit hard to make something useful from 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

Jeff Mesnil
In reply to this post by Heiko Braun

Le 25 févr. 2013 à 17:47, Heiko Braun <[hidden email]> a écrit :
> Do notification types have different TTL's? (i.e. MOTD)

I don't think that a TTL makes sense for a notification.

A notification is just a description of an event that *already occurred*. The only meaningful date you have is the timestamp of the notification (that is an approximation of the time when the event that triggered the notification occurred).

Let's take the example of resources added/removed.
If you receive a notification RESOURCE_ADDED for the resource A with the timestamp T, the only thing you know for sure is that the resource was added at that time.
But this does not mean that the resource still exists when you handle the notification if it has been removed in the meantime. Even in that case, the notification is still exact and you will eventually receive a RESOURCE_REMOVED notification later on in that case.

Receiving notifications trough polling or push notifications does not change that: you only receive notifications after the event occurred and you can only react to the past.

Does that make sense?

--
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

kkhan

On 26 Feb 2013, at 12:09, Jeff Mesnil wrote:

>
> Le 25 févr. 2013 à 17:47, Heiko Braun <[hidden email]> a écrit :
>> Do notification types have different TTL's? (i.e. MOTD)
>
> I don't think that a TTL makes sense for a notification.
>
> A notification is just a description of an event that *already occurred*. The only meaningful date you have is the timestamp of the notification (that is an approximation of the time when the event that triggered the notification occurred).
>
> Let's take the example of resources added/removed.
> If you receive a notification RESOURCE_ADDED for the resource A with the timestamp T, the only thing you know for sure is that the resource was added at that time.
> But this does not mean that the resource still exists when you handle the notification if it has been removed in the meantime. Even in that case, the notification is still exact and you will eventually receive a RESOURCE_REMOVED notification later on in that case.
>
> Receiving notifications trough polling or push notifications does not change that: you only receive notifications after the event occurred and you can only react to the past.
>
> Does that make sense?
>
Yes. I started writing some stuff about making unconsumed notifications being aware of each other so if there for example was an unconsumed ADD followed by a REMOVE, the REMOVE would cancel the ADD. This really didn't make sense so I stopped writing :-) A listener might need to do something to handle both events so as long as an address has listeners registered I think the notifications should always be sent.


> --
> 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
It makes sense if we speak about async callbacks to notification handlers. But for the polling based approached you described, there will be time T between each client poling for notifications. Now if notifications are not kept (persisted somehow, memory or otherwise) for that window clients will miss them. That's the TTL i was talking about.


On Feb 26, 2013, at 1:09 PM, Jeff Mesnil <[hidden email]> wrote:

>
> Le 25 févr. 2013 à 17:47, Heiko Braun <[hidden email]> a écrit :
>> Do notification types have different TTL's? (i.e. MOTD)
>
> I don't think that a TTL makes sense for a notification.
>
> A notification is just a description of an event that *already occurred*. The only meaningful date you have is the timestamp of the notification (that is an approximation of the time when the event that triggered the notification occurred).
>
> Let's take the example of resources added/removed.
> If you receive a notification RESOURCE_ADDED for the resource A with the timestamp T, the only thing you know for sure is that the resource was added at that time.
> But this does not mean that the resource still exists when you handle the notification if it has been removed in the meantime. Even in that case, the notification is still exact and you will eventually receive a RESOURCE_REMOVED notification later on in that case.
>
> Receiving notifications trough polling or push notifications does not change that: you only receive notifications after the event occurred and you can only react to the past.
>
> Does that make sense?
>
> --
> 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

Le 26 févr. 2013 à 13:57, Heiko Braun <[hidden email]> a écrit :

> It makes sense if we speak about async callbacks to notification handlers. But for the polling based approached you described, there will be time T between each client poling for notifications. Now if notifications are not kept (persisted somehow, memory or otherwise) for that window clients will miss them. That's the TTL i was talking about.

Ah ok, I see.

Yes, with a polling-based approach, we would have to keep the notifications until the HTTP client fetches them.
I'd keep it simple and have a rolling buffer for each notification handlers would be enough: e.g. keeping only the 1K most recent notifications.
Every time the HTTP client fetch them (with a POST), the buffer is flushed so the memory constraint is bounded.

The QoS of remote notifications should be clearly stated. I don't think we need to provide reliability (keeping the notifications until the HTTP clients acknowledges them) or persistence (keeping notifications upon server restart).
If the clients really need that type of QoS from notifications, he'd be better served using a messaging system instead[1] :)

jeff

[1] HornetQ allows to receive notifications using a JMS destination instead of using a remote JMX connector.
--
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

David Lloyd-2
In reply to this post by Jeff Mesnil
On 02/15/2013 11:00 AM, Jeff Mesnil wrote:
> 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).

I don't know, it seems like overkill.  I think
http://html5doctor.com/server-sent-events/ is probably a better option
than web sockets or polling as it is supported in the browser with a
simple API and doesn't require a lot of complex server-side support.

--
- DML
_______________________________________________
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 Dimitris Andreadis
I agree with this architecturally. But I think it's the JSR-160 analogue
that makes the effort worth doing in the first place.

On 2/26/13 4:49 AM, Dimitris Andreadis wrote:

> 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
>>
>


--
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 David Lloyd-2

Le 26 févr. 2013 à 18:37, David M. Lloyd <[hidden email]> a écrit :

> On 02/15/2013 11:00 AM, Jeff Mesnil wrote:
>> 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).
>
> I don't know, it seems like overkill.  I think
> http://html5doctor.com/server-sent-events/ is probably a better option
> than web sockets or polling as it is supported in the browser with a
> simple API and doesn't require a lot of complex server-side support.

HTML5 server-sent events looks interesting and I like their simplicity.
The only thing I don't like is that the client can only send parameters using the URL to connect to the event source. That makes for looong URL if you want to listen to multiple resources.
For example, to listen to notifications on hornetq-server, jms-queue & jms-topic, the client must connect to:

/notification/sse?address=/subsystem%3Dmessaging/hornetq-server%3D*&address=/subsystem%3Dmessaging/hornetq-server%3D*/jms-queue%3D*&address=/subsystem%3Dmessaging/hornetq-server%3D*/jms-topic%3D*

Using WebSocket makes the communication between the client and the server much straightforward (and similar to the resources of the HTTP API).

I cooked up a quick & dirty prototype with our current HTTP server[1] and it works fine (but not efficiently).
I checked it with the latest chrome/safari/firefox and all worked as expected.
However IE does not support them at the moment[2] and we'd have to provide a polyfill for it.

Web Socket support is more widespread[3] and it seems there is more activity around WebSocket than server-sent events (when they are comparable…)
Undertow provides a WebSocket support that we can leverage and hides the complexity (from the management pov).

Server-sent events:
* pros
  * simple
  * work with our current management HTTP server
* cons
  * no IE support means to provide a polyfill alternative (identical to long polling)
  * long URL (I worry we could hit a limit if the browser want a single event source to list to many resources)

WebSockets:
* pros
  * widespread support
  * richer communication from the client to the server
* cons
  * not working today (depends on undertow that should be integrated soon)

I don't have a sting opinion on this but I'd favor the WebSocket technology.
Our web browser experts should have a say on what they'd prefer use.

jeff

[1] https://github.com/jmesnil/jboss-as/blob/AS7-370_notification_with_server-sent_events/domain-http/interface/src/main/java/org/jboss/as/domain/http/server/NotificationApiHandler.java#L219
[2] http://caniuse.com/#feat=eventsource
[3] http://caniuse.com/#feat=websockets

--
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
Thanks, Jeff, for your fast work on this. I agree we need feedback from
Heiko and other client-side folks.

We should assume we'll be using undertow.

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

>
> Le 26 févr. 2013 à 18:37, David M. Lloyd <[hidden email]> a écrit :
>
>> On 02/15/2013 11:00 AM, Jeff Mesnil wrote:
>>> 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).
>>
>> I don't know, it seems like overkill.  I think
>> http://html5doctor.com/server-sent-events/ is probably a better option
>> than web sockets or polling as it is supported in the browser with a
>> simple API and doesn't require a lot of complex server-side support.
>
> HTML5 server-sent events looks interesting and I like their simplicity.
> The only thing I don't like is that the client can only send parameters using the URL to connect to the event source. That makes for looong URL if you want to listen to multiple resources.
> For example, to listen to notifications on hornetq-server, jms-queue & jms-topic, the client must connect to:
>
> /notification/sse?address=/subsystem%3Dmessaging/hornetq-server%3D*&address=/subsystem%3Dmessaging/hornetq-server%3D*/jms-queue%3D*&address=/subsystem%3Dmessaging/hornetq-server%3D*/jms-topic%3D*
>
> Using WebSocket makes the communication between the client and the server much straightforward (and similar to the resources of the HTTP API).
>
> I cooked up a quick & dirty prototype with our current HTTP server[1] and it works fine (but not efficiently).
> I checked it with the latest chrome/safari/firefox and all worked as expected.
> However IE does not support them at the moment[2] and we'd have to provide a polyfill for it.
>
> Web Socket support is more widespread[3] and it seems there is more activity around WebSocket than server-sent events (when they are comparable…)
> Undertow provides a WebSocket support that we can leverage and hides the complexity (from the management pov).
>
> Server-sent events:
> * pros
>    * simple
>    * work with our current management HTTP server
> * cons
>    * no IE support means to provide a polyfill alternative (identical to long polling)
>    * long URL (I worry we could hit a limit if the browser want a single event source to list to many resources)
>
> WebSockets:
> * pros
>    * widespread support
>    * richer communication from the client to the server
> * cons
>    * not working today (depends on undertow that should be integrated soon)
>
> I don't have a sting opinion on this but I'd favor the WebSocket technology.
> Our web browser experts should have a say on what they'd prefer use.
>
> jeff
>
> [1] https://github.com/jmesnil/jboss-as/blob/AS7-370_notification_with_server-sent_events/domain-http/interface/src/main/java/org/jboss/as/domain/http/server/NotificationApiHandler.java#L219
> [2] http://caniuse.com/#feat=eventsource
> [3] http://caniuse.com/#feat=websockets
>


--
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
In reply to this post by David Lloyd-2
SSE are asynchronous, but unidirectional. Whereas websockets are asynchronous and bidirectional.

Enabling push through SSE,  clients could use a combination of request/response for the main communication (i.e. execution of operations, reading the model contents, etc) and SSE for the notifications .

Using websockets we could move all client communication to one paradigm. But do we need it?

Currently have cases where clients keep polling for system state changes (i.e. server restart, deployments, etc). Typically the things that take some time to complete. So I am wondering if these cases could benefit from an asynchronous bidirectional communication channel. But I guess this depends on how the DC processes management operations and if asynchronous responses would fit into the picture. 


/Heiko


On Feb 26, 2013, at 6:37 PM, David M. Lloyd <[hidden email]> wrote:

I don't know, it seems like overkill.  I think 
http://html5doctor.com/server-sent-events/ is probably a better option 
than web sockets or polling as it is supported in the browser with a 
simple API and doesn't require a lot of complex server-side support.


_______________________________________________
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

David Lloyd-2
I don't see notifications as a bidirectional thing.  I look at it this way:

sync:
   C: "Please send me notifications regarding /foo=bar to id=123"
   S: "OK, will do"
   C: "Please send me notifications regarding /baz=zap to id=123"
   S: "There is no such resource, sorry"
   ...

In the meantime, you have:
async:
   C: "Notifications for id=123"
   S: "/foo=bar changed ..."
   S: "/foo=bar changed ..."
   ...
   (connection broken - cell phone went into a tunnel)
   C: "Notifications for id=123"
   S: "/foo=bar changed ..."
   ...

It seems a very clean mapping, cleaner than web sockets tbh, and a sight
simpler architecturally.

I do not see async notifications as a good solution for long-running
operations since those are essentially synchronous.  I'd rather see a
server-side solution for that (even the outliers like restarting a
server).  Trying to make these asynchronous is sort of the path of most
resistance, in that we're borrowing complexity we do not need.

On 02/27/2013 01:43 PM, Heiko Braun wrote:

> SSE are asynchronous, but unidirectional. Whereas websockets are
> asynchronous and bidirectional.
>
> Enabling push through SSE,  clients could use a combination of
> request/response for the main communication (i.e. execution of
> operations, reading the model contents, etc) and SSE for the notifications .
>
> Using websockets we could move all client communication to one paradigm.
> But do we need it?
>
> Currently have cases where clients keep polling for system state changes
> (i.e. server restart, deployments, etc). Typically the things that take
> some time to complete. So I am wondering if these cases could benefit
> from an asynchronous bidirectional communication channel. But I guess
> this depends on how the DC processes management operations and if
> asynchronous responses would fit into the picture.
>
>
> /Heiko
>
>
> On Feb 26, 2013, at 6:37 PM, David M. Lloyd <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>> I don't know, it seems like overkill.  I think
>> http://html5doctor.com/server-sent-events/is probably a better option
>> than web sockets or polling as it is supported in the browser with a
>> simple API and doesn't require a lot of complex server-side support.
>


--
- DML
_______________________________________________
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
On 2/27/13 2:12 PM, David M. Lloyd wrote:

> I don't see notifications as a bidirectional thing.  I look at it this way:
>
> sync:
>     C: "Please send me notifications regarding /foo=bar to id=123"
>     S: "OK, will do"
>     C: "Please send me notifications regarding /baz=zap to id=123"
>     S: "There is no such resource, sorry"
>     ...
>
> In the meantime, you have:
> async:
>     C: "Notifications for id=123"
>     S: "/foo=bar changed ..."
>     S: "/foo=bar changed ..."
>     ...
>     (connection broken - cell phone went into a tunnel)
>     C: "Notifications for id=123"
>     S: "/foo=bar changed ..."
>     ...
>
> It seems a very clean mapping, cleaner than web sockets tbh, and a sight
> simpler architecturally.
>
> I do not see async notifications as a good solution for long-running
> operations since those are essentially synchronous.  I'd rather see a
> server-side solution for that (even the outliers like restarting a
> server).  Trying to make these asynchronous is sort of the path of most
> resistance, in that we're borrowing complexity we do not need.
>

We actually built a side-channel event mechanism into the core operation
execution API:

org.jboss.as.controller.client.OperationMessageHandler

We never really did anything with it though after 7.0.0.Beta1. For
7.0.0.Alpha1 I had prototype stuff for sending back events as
domain-wide operations execute. But it got ripped out as a bridge too far.

A browser-based client would of course need a different mechanism for
registering for messages and having them be propagated back.

> On 02/27/2013 01:43 PM, Heiko Braun wrote:
>> SSE are asynchronous, but unidirectional. Whereas websockets are
>> asynchronous and bidirectional.
>>
>> Enabling push through SSE,  clients could use a combination of
>> request/response for the main communication (i.e. execution of
>> operations, reading the model contents, etc) and SSE for the notifications .
>>
>> Using websockets we could move all client communication to one paradigm.
>> But do we need it?
>>
>> Currently have cases where clients keep polling for system state changes
>> (i.e. server restart, deployments, etc). Typically the things that take
>> some time to complete. So I am wondering if these cases could benefit
>> from an asynchronous bidirectional communication channel. But I guess
>> this depends on how the DC processes management operations and if
>> asynchronous responses would fit into the picture.
>>
>>
>> /Heiko
>>
>>
>> On Feb 26, 2013, at 6:37 PM, David M. Lloyd <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>> I don't know, it seems like overkill.  I think
>>> http://html5doctor.com/server-sent-events/is probably a better option
>>> than web sockets or polling as it is supported in the browser with a
>>> simple API and doesn't require a lot of complex server-side support.
>>
>
>


--
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
In reply to this post by David Lloyd-2
Agreed. Let's move forward with SSE.

On Feb 27, 2013, at 9:12 PM, David M. Lloyd <[hidden email]> wrote:

It seems a very clean mapping, cleaner than web sockets tbh, and a sight simpler architecturally.


_______________________________________________
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
I've updated the documentation about adding notification to AS7[1]

I think I've defined the most important parts that clients needs to know to deal with AS7 notifications:

* describe notifications in AS7 resource model
* define global notifications supported by all resources
* AS7 service to register/unregister local listener + emit notifications
* HTTP API
  * plain HTTP with polling notifications
  * Web-browser specific to push notifications using Server-sent events
* extra methods to the Java management API to register/unregister listeners in Java clients

Note the doc does not define all the notifications that can be emitted by AS7 resources.
The idea is that the AS7 resource model describes them (like attributes and operations) so that the client can use the description to know which resources emit notifications (and their types).

jeff

[1] 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

Heiko Braun

I have some questions regarding your example, where you describe that a notification is emitted (n1) when an attribute value changed and a client (curl) executes two subsequent POST requests (p1, p2) to fetch notifications.

I am wondering what the semantics are for processing/delivering notifications. What can clients expect?

- Stream of notifications: Clients get to see what exists at a given point in time. There is the possibility to miss notifications.

- Durable subscriptions: Regardless of a clients availability and polling interval, it will always get all notifications since the last time it connected. It's not possible to miss notifications.

- Time windows: Notifications are kept for a certain amount of time, during that interval clients get the same snapshot, regardless how many times they poll? It's possible to miss notifications if the polling frequency is much bigger then the window size.

 
Regards, Heiko

On Mar 5, 2013, at 6:11 PM, Jeff Mesnil <[hidden email]> wrote:

> I've updated the documentation about adding notification to AS7[1]
>
> I think I've defined the most important parts that clients needs to know to deal with AS7 notifications:
>
> * describe notifications in AS7 resource model
> * define global notifications supported by all resources
> * AS7 service to register/unregister local listener + emit notifications
> * HTTP API
>  * plain HTTP with polling notifications
>  * Web-browser specific to push notifications using Server-sent events
> * extra methods to the Java management API to register/unregister listeners in Java clients
>
> Note the doc does not define all the notifications that can be emitted by AS7 resources.
> The idea is that the AS7 resource model describes them (like attributes and operations) so that the client can use the description to know which resources emit notifications (and their types).
>
> jeff
>
> [1] 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


_______________________________________________
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

Le 6 mars 2013 à 08:53, Heiko Braun <[hidden email]> a écrit :

>
> I have some questions regarding your example, where you describe that a notification is emitted (n1) when an attribute value changed and a client (curl) executes two subsequent POST requests (p1, p2) to fetch notifications.
>
> I am wondering what the semantics are for processing/delivering notifications. What can clients expect?
>
> - Stream of notifications: Clients get to see what exists at a given point in time. There is the possibility to miss notifications.
>
> - Durable subscriptions: Regardless of a clients availability and polling interval, it will always get all notifications since the last time it connected. It's not possible to miss notifications.
>
> - Time windows: Notifications are kept for a certain amount of time, during that interval clients get the same snapshot, regardless how many times they poll? It's possible to miss notifications if the polling frequency is much bigger then the window size.

None of the above.

I describe it at the end of this section[1]  but it may not be not clear enough.

One each POST request, the client will receive the N most recent notifications that were emitted since its last POST request. Once the POST response is sent, the server will flush the notifications held for this client. He will not receive twice the same notification.
It is possible to miss notifications if the client does not poll often enough and there are more than N notifications emitted. This is a compromise to prevent exhausting server memory by having clients register a listener and never poll its notifications that'll fill up the memory.
Having a sensible value for N (e.g. 1024) should leave enough time for a client to poll regularly and not miss most notifications.

Does that answer your question?

jeff

[1] https://community.jboss.org/wiki/AddNotificationSupportToTheDomainManagementAPI#Notification_Handlers_Notifications_Resource

--
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


Thanks, I think that answers my question. Almost :)

I assume N is a system wide configuration property and not a per request parameter? In that case it's probably the number of all notifications and not per resource? Or per registered handler? 

On Mar 6, 2013, at 11:48 AM, Jeff Mesnil <[hidden email]> wrote:

I describe it at the end of this section[1]  but it may not be not clear enough.

One each POST request, the client will receive the N most recent notifications that were emitted since its last POST request. Once the POST response is sent, the server will flush the notifications held for this client. He will not receive twice the same notification.
It is possible to miss notifications if the client does not poll often enough and there are more than N notifications emitted. This is a compromise to prevent exhausting server memory by having clients register a listener and never poll its notifications that'll fill up the memory.
Having a sensible value for N (e.g. 1024) should leave enough time for a client to poll regularly and not miss most notifications.

Does that answer your question?


_______________________________________________
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

Le 6 mars 2013 à 13:10, Heiko Braun <[hidden email]> a écrit :

>
>
> Thanks, I think that answers my question. Almost :)
>
> I assume N is a system wide configuration property and not a per request parameter? In that case it's probably the number of all notifications and not per resource? Or per registered handler?

I see it as a system-wide configuration property.
It's the number of notifications per registered handler (each handler registered through the HTTP has its own buffer of notifications).

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
123