[wildfly-dev] Gathering diagnostic data

[Brian Stansberry]

On 2/25/14, 10:38 PM, James Livingston wrote:
> On Tue, 2014-02-25 at 22:11 -0600, Brian Stansberry wrote:
>> On 2/25/14, 9:30 PM, David M. Lloyd wrote:
>>> On 02/25/2014 09:26 PM, James Livingston wrote:
>>>> Is this something that might be possible or a good idea to do? I have
>>>> some ideas about other things that may be useful, like per-thread CPU
>>>> usage which RH support currently uses a pile of shell scripts for, but
>>>> starting with one thing may be simpler.
>>>
>>> I believe that the management model that is already defined for host
>>> controllers' views of their servers could easily accommodate this kind
>>> of thing.  I don't think it'd have to be an extension - in fact, it
>>> probably should not be in this case.
>>>
>>
>> Agreed.
>
> Thanks David and Brian. I'll take a look at adding it there, using my
> in-progress code to abstract over the JDK/OS specific details of
> grabbing the data. I've created
> https://issues.jboss.org/browse/WFLY-3025 for it.
>
>
> The most common mechanism for getting a thread dump is on the
> Hotspot-specific implementation of the Attach API, which (unfortunately)
> returns a blob of text. Parsing it isn't too hard, but it isn't
> standardised and newer JDK releases may emit it in a slightly different
> form.
>
> Would it be best to just return the dump as a giant string, or attempt
> to returning it as a well structured model, with a fallback if parsing
> fails. The latter would be better for tools, such as if the console ever
> wanted to do anything with the information, but we have to deal failures
> to parse the data.
>

You either need to provide 2 ops, or the details with no fallback, or 
just the unstructured text. It can't be a single op that provides well 
structured data except if something goes wrong in which case it provides 
unstructured text. The metadata for an op describes the structure of the 
return data, and that description can't be ambiguous.

I think starting with a just-text op is best and then let your users 
help drive your roadmap.

-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat