[jboss-as7-dev] 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 <lkrejci at redhat.com> 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 <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
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-as7-dev/attachments/20130225/c23b7e34/attachment.html