<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div><div>Some additional notification types that admins could make use of:</div><div><br></div><div>- <span style="background-color: rgb(255, 255, 255); color: rgb(85, 85, 85); font-family: 'Lucida Sans', 'Lucida Sans Unicode', 'Lucida Grande', Verdana, Arial, Helvetica, sans-serif; font-size: 12px; text-align: left; ">SERVER_NEEDS_RELOAD</span></div><div><span style="background-color: rgb(255, 255, 255); color: rgb(85, 85, 85); font-family: 'Lucida Sans', 'Lucida Sans Unicode', 'Lucida Grande', Verdana, Arial, Helvetica, sans-serif; font-size: 12px; text-align: left; ">- </span><span style="background-color: rgb(255, 255, 255); color: rgb(85, 85, 85); font-family: 'Lucida Sans', 'Lucida Sans Unicode', 'Lucida Grande', Verdana, Arial, Helvetica, sans-serif; font-size: 12px; text-align: left; ">AUTHENTICATION / USER_LOGGED_ON</span></div><div><span style="background-color: rgb(255, 255, 255); color: rgb(85, 85, 85); font-family: 'Lucida Sans', 'Lucida Sans Unicode', 'Lucida Grande', Verdana, Arial, Helvetica, sans-serif; font-size: 12px; text-align: left; ">- </span><span style="background-color: rgb(255, 255, 255); color: rgb(85, 85, 85); font-family: 'Lucida Sans', 'Lucida Sans Unicode', 'Lucida Grande', Verdana, Arial, Helvetica, sans-serif; font-size: 12px; text-align: left; ">SYSTEM_IS_GOING_TO_SHUTDOWN</span></div><div><span style="background-color: rgb(255, 255, 255); color: rgb(85, 85, 85); font-family: 'Lucida Sans', 'Lucida Sans Unicode', 'Lucida Grande', Verdana, Arial, Helvetica, sans-serif; font-size: 12px; text-align: left; ">- </span><span style="background-color: rgb(255, 255, 255); color: rgb(85, 85, 85); font-family: 'Lucida Sans', 'Lucida Sans Unicode', 'Lucida Grande', Verdana, Arial, Helvetica, sans-serif; font-size: 12px; text-align: left; ">MESSAGE_OF_THE _DAY</span></div><div><br></div><div>I can see the value in these from an administrator point of view. But it raises an interesting question:</div><div><br></div><div>Do notification types have different TTL's? (i.e. MOTD)</div><div><br></div><br><div><div>On Feb 25, 2013, at 2:31 PM, Lukas Krejci <<a href="mailto:lkrejci@redhat.com">lkrejci@redhat.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">On Monday, February 25, 2013 12:00:11 Heiko Braun wrote:<br><blockquote type="cite">If we intend to provide support for polling it means the notifications need<br>to be kept in memory.<br><br>- What constraints do apply in this case? (I.e. TTL and MAX notification<br>count?) - How does the design of this approach allow us to transition into<br>a push based mechanism?<br><br></blockquote><br>I may be wrong but I can't see the server creating thousands of notifications <br>per hour (or even per day). These are notifications about configuration changes <br>and you don't reconfigure your server every few minutes.<br><br>So while TTL and MAX are valid concerns, I don't think it would be a massive <br>problem to set them both to Integer.MAX_INT.<br><br>An interesting, but possibly more complex to implement, would be the <br>suggestion Heiko R. was saying with "clear the notiification queue once client <br>reads it". This would possibly require some kind of client registration (so <br>that mulitple clients can poll for notifs and don't "steal" them from each <br>other by reading them) and possibly some permanent storage for them to survive <br>a restart of the server. Essentially notifs would become some kind of config <br>change journal. But that may be too much.<br><br><blockquote type="cite">Overall I am not sure a poll based solution adds any value to the current<br>architecture. This is what we already do and it doesn't require any interim<br>format, i.e. we directly poll for the existence of server resources. But<br>maybe I am missing something here?<br><br></blockquote><br>One benefit I can see is the reduced load on the server. Instead of flooding the <br>server with potentially thousands of poll requests (if the client is not <br>careful and doesn't spread the requests in time), you only poll for the list <br>of notifications.<br><br><blockquote type="cite">Regards, Heiko<br><br>On Feb 22, 2013, at 6:32 PM, Jeff Mesnil <<a href="mailto:jmesnil@redhat.com">jmesnil@redhat.com</a>> wrote:<br><blockquote type="cite">I've updated the doc[1] to focus on the web console use case and the<br>minimal requirements it has.<br><br>I wrote a simple plain HTTP API (no WebSockets, working with cURL) that<br>should be enough for the Web console to handle notifications.<br><br>Since it's HTTP only, the console would still have to poll but:<br><br>1. It will have few well-defined HTTP resources to poll<br>2. There is an explicit contract for the notifications instead of<br>extracting information from the different responses it get from the<br>server.<br><br>This API should be suitable to http-based clients and when undertow is<br>available in AS7, we could provide a WebSocket upgrade on its URL<br>endpoints to push notifications to the browser.<br><br>jeff<br></blockquote></blockquote>_______________________________________________<br>jboss-as7-dev mailing list<br><a href="mailto:jboss-as7-dev@lists.jboss.org">jboss-as7-dev@lists.jboss.org</a><br>https://lists.jboss.org/mailman/listinfo/jboss-as7-dev<br></blockquote></div><br></body></html>