[wildfly-dev] Domain Overview design

[Brian Stansberry]

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

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