Thanks for answering my questions!
----- Original Message -----
From: "Brian Stansberry"
To: "Liz Clayton" <lclayton(a)redhat.com>
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
> 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
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
>> 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
>> 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.