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

[Lukas Krejci]

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 <jmesnil at redhat.com> 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