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

[Brian Stansberry]

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


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat