[wildfly-dev] Domain Overview design

[Liz Clayton]

Hi,

Thanks for answering my questions!

----- Original Message -----
> From: "Brian Stansberry" <brian.stansberry at redhat.com>
> To: "Liz Clayton" <lclayton at redhat.com>
> Cc: wildfly-dev at 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