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

[Dimitris Andreadis]

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

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

http://dandreadis.blogspot.com/