Bill,
Thanks for your detailed review. Pl. see my comments in line.
I have cc'd arch_at_glassfish as suggested by you.
thanks
sreeni
Bill Shannon wrote:
> Sreenivas Munnangi wrote:
>
>> Bill,
>>
>> You are aware that v3 monitoring uses BTrace for transforming the
>> classes at runtime. To provide for attaching the btrace-agent on
>> demnad, we initially came up with attach-agent command. Considering
>> usability the command was renamed to enable-monitoring. When it is
>> renamed, people (including QA and Docs) saw several other uses for
>> this command including enabling/disabling over-all-monitoring,
>> dtrace, mbeans, and module-levels. The commands enable-monitoring and
>> disable-monitoring in its present form are given below.
>>
>> 4.1.6.2. asadmin enable-monitoring/disable-monitoring
>>
>> The monitoring funcationality including attaching btrace-agent is
>> done based on the 'monitoring-enabled' attribute of
>> 'monitoring-service' element. If monitoring-enabled is true then the
>> btrace-agent is attached as part of startup. When monitoring-enabled
>> is false, btrace-agent is not attached at startup time. However when
>> user changes monitoring-enabled to true while the server is running,
>> it should be possible to attach the btrace-agent and start monitoring
>> functionality.
>>
>> Purpose of this pair of commands is to provide enable /disable
>> monitoring during run time without having to restart the server
>> (Alternatively user should be able to use asadmin set command to
>> enbale/disable the monitoring-enabled flag, but have to restart the
>> server to take effect). It does attach btrace-agent based on the
>> given pid and optionally sets the monitoring level for given modules.
>>
>> enable-monitoring
>>
>> enable-monitoring [--mbean=false] [--dtrace*=true] [--level
>> web-container="LOW":ejb-container="HIGH"] [--options="debug=true"]
>> [--pid=<pid>]
>>
>> * enable-monitoring
>> sets the attribute 'monitoring-enabled' to 'true'
>> * enable-monitoring --mbean=true --dtrace*=false
>> sets the attribute 'monitoring-enabled' to 'true', mbean-enabled
>> to true and dtrace-enabled to false
>> * enable-monitoring --options="debug=true" --pid=<pid>
>> sets the attribute 'monitoring-enabled' to 'true' and attaches
>> btrace agent using --options
>> * enable-monitoring --level web-container="LOW":ejb="HIGH"
>> sets the levels for given modules in addition to
>> 'monitoring-enabled'
>
>
> What process does the pid refer to?
Application server's jvm process.
>
> While either is allowed, we normally recommend that people omit the "="
> for non-boolean options - "--options debug=true", "--pid <pid>", etc.
>
I'll fix the command syntax accordingly.
> What is the set of valid options to --options? Perhaps it should be
> called
> --property for consistency with other commands?
These are the options for btrace-agent and they are
dumpClasses=false,debug=false,unsfae=false,probeDescPath=/foo/bar,noServer=true,script=$1
>
> What are the valid values for --level?
>
OFF, LOW and HIGH
> There should be no need for quotes in --level:
> --level web-container=LOW:ejb=HIGH
>
I'll fix it.
> Why "web-container" and "ejb" instead of "web" and "ejb" or
> "web-container"
> and "ejb-container"?
>
Actually it is web-container and ejb-container.
> I don't remember how mbeans come into play here.
>
For v2 compatability, we expose monitoring data also thru amx mBeans. If
for some reason, the user does not want mBeans then the mbean flag can
be used not to create monitoring mBeans, for ex. mbean="false".
>> disable-monitoring
>>
>> disable-monitoring --modules="web-container,ejb-container"
>>
>> * disable-monitoring
>> sets the attribute 'monitoring-enabled' to 'false'
>> * disable-monitoring --modules="web-container,ejb-container"
>> this command will just set the levels for given modules to 'OFF'
>> and it does not change the value for 'monitoring-enabled'
>
>
> Why is it "ejb-container" here?
It should have been ejb-container all the time.
>
>> *- Available as a value-add feature, made available only to the paid
>> customers.
>>
>> Above also caters an important use case of adhoc monitoring, i.e.
>> turning monitoring on in production while server is running, for ex.
>> enable dtrace on the fly.
>>
>> I have added the above to monitoring one pager and request your
>> review/comments.
>> http://wiki.glassfish.java.net/attach/V3FunctionalSpecs/monitoring-one-pager-v3ms2.html#41
>>
>>
>> Pl. let me know if you need any additional info or if you have any
>> questions.
>
>
> Other than the above, it seems fine to me. Maybe you should send this
> to arch_at_glassfish as well?