Re: [wildfly-dev] Domain Overview design

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.

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