[wildfly-dev] Domain Overview design

[Liz Clayton]

Hi,

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

Thanks for sending this pointer! I read through the thread and have a few more questions:
- Sounds like there are some terminology issues to reconcile as part of this?
- Should these shutdown states be represented in the visualization? If so, do you think they should be represented as:
* A graduated scale of availability (shades of yellow/orange), to reflect the various states of suspension or “out of sync” ness?
- or -
* A single “out of sync” (suspended?) state? If that were the case, perhaps “out of sync” could be represented as an intermediate (yellow/orange) state between green and red. Details about the state could be presented in a hover overlay, with a link to perform the action needed ("restart" for example). 

Thanks,
-Liz



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