Re: [wildfly-dev] Domain Overview design

From: "Brian Stansberry" <brian.stansberry(a)redhat.com&gt; To: "Liz Clayton" <lclayton(a)redhat.com&gt; Cc: wildfly-dev(a)lists.jboss.org Sent: Tuesday, August 5, 2014 1:51:53 PM Subject: Re: [wildfly-dev] Domain Overview design On 7/29/14, 1:44 PM, Liz Clayton wrote: > Hi, > > Thanks for answering my questions! > > ----- Original Message ----- >> From: "Brian Stansberry" <brian.stansberry(a)redhat.com&gt; >> To: "Liz Clayton" <lclayton(a)redhat.com&gt; >> Cc: wildfly-dev(a)lists.jboss.org >> Sent: Friday, July 25, 2014 5:40:30 PM >> Subject: Re: [wildfly-dev] Domain Overview design >> > ... >>> The boxes are irregular on 16 because they were intended to display mini >>> heatmaps, stacked. And unlike the domain-view version (pg15) where the >>> size of the box would be driven by # of servers - the mini ones could be >>> scaled by some other metric (throughput or etc.). But I didn't really >>> have >>> that information, so I made the boxes uniformly sized. >>> >> >> I see; so the thought was perhaps the user could choose a scaling factor >> or something? > > I hadn't thought about it being a user selection, but that's an interesting > idea. > > ... >>>> There's also a similar notion regarding how consistent the server's >>>> running state is with its persistent configuration. Admins can make >>>> configuration changes that will not take effect until the server is >>>> reloaded or restarted. >>> >>> Would that directly affect its availability status? >>> >> >> No, it wouldn't. The server goes into this state when the admin makes a >> config change that the server can't apply to its running services >> without affecting their ability to handle end-user requests. The server >> doesn't "just do it", it goes into this state which lets the admin know >> they need to take an action that *will* temporarily affect availability. >> >>>> I'm not sure if those things are well represented on a green-yellow-red >>>> color continuum because they are somewhat different from server health. >>>> But they are important pieces of data to visualize. > > So there's server health (availability), & server "state", and they are > both useful bits of high-level info. > Just an FYI -- there was a thread on this list in June about exposing status information related to graceful shutdown. It's a pretty convoluted thread, but here's a hopefully useful conclusion point: http://lists.jboss.org/pipermail/wildfly-dev/2014-June/002360.html

>>> yes, great to know about. >>> >>>> "How does the Alerts tab fit in with the *current* Notification message >>>> queue?" >>>> >>>> Heiko Braun knows better, but I don't see a close fit. The current queue >>>> isn't really based on any sort of server-push of events. The console >>>> makes administrative requests and gets responses; if relevant that >>>> request/response results in stuff in the queue. But anything that >>>> happens outside of those requests/responses is unknown to the console. >>> >>> So there are events happening on the system, that could affect >>> availability, which will not show up in the message queue? >>> >> >> Absolutely. The console only knows what it specifically asks or the >> effect of changes it makes, plus a small bit of status information that >> gets piggy-backed in the response to requests (i.e. that the server is >> in reload/restart-required state.) But the user's app could be throwing >> errors all over the place, resources like memory or thread pools could >> be overtaxed, etc, and the console would have no clue unless it check >> those specific things. > > OK, thanks! > > -Liz > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat