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@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev