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