Comments (beyond Nazrul's):
llc-01 Monitoring via JMX could happen for Prelude, but seems
"tight". JMX+Notifications should be added to the API stack in 4.1.0.
llc-02 the creation and removal and listing/status of probes should
be exposed via JMX I think. Perhaps an annotation to that effect can
be placed upon a probe. Then the GUI could easily search for and fine
all probes, as well as create and remove them.
llc-03 I'm a bit confused by section 4.1.1.5. If it is a zero
overhead system, why is the TransactionManagerImpl doing explicit
calls to onTxBegin? Or is it that this always needs to be done, and
the probe can be one of the listeners?
llc-04 The ProviderRegistry and ProbeProviderInfo looks perfect for
exposing via MBeans.
llc-05 The Stats classes as well as Maps are awkward in a CLI. Is
there a better way to expose this data?
llc-06 In 4.1.2.5, monitoring seems to be based on config dotted
names. But the components to be monitored are often runtime entities
which don't exist in config eg Servlets.
llc-07 For compatibility layer we may need "get --monitor". But the
V3 final dotted names will not distinguish that way; dotted names are
pervasive and share one hierarchy for all names.
llc-08 Packages names include "gfprobe" but others use
"flashlight". Shouldn't they share the same terminology?
Lloyd
..............................................
Lloyd Chambers
lloyd.chambers_at_sun.com
GlassFish team, admin
On Jul 17, 2008, at 11:37 PM, Nazrul Islam wrote:
> Prashanth Abbagani wrote:
>>
>> Initial draft of Monitoring one pager for V3 Prelude is available.
>> Please take a took and provide feedback, comments, concerns, if any.
>>
>> http://wiki.glassfish.java.net/Wiki.jsp?page=GFV3MonitoringOnePager
> Thanks for starting this thread. Here are some notes from today's
> review...
> 1) Section 4.1.2.3.3: Please ensure that the object view hierarchy
> is aligned with GFv2 and the dotted names are backward compatible.
> 2) Section 4.1.2.5: Please ensure that monitor_type is correctly
> mapped for GFv2 types also.
> 3) Section 4.1.2.5: asadmin set command does not work without
> domain.xml persistence.
> 4) Section 4.12: Please specify how GFv2 monitoring levels (OFF,
> LOW, HIGH) will work.
> 5) Please ensure that this works for both JDK 5 and JDK6.
> 6) Please expose the monitoring information with JMX MBeans. REST
> support may come post Prelude.
> 7) Please check all the APIs for naming consistency and align.
> 8) Secion 4.1.1.1: Please specify that appName can be null.
> 9) Section 4.3: Please specify what is in scope for GFv3 Prelude.
> 10) Section 4.4: Please clearly specify what is out of scope so that
> future design goals are understood.
> 11) Section 4.5.1.2: Do we need to expose the probe annotations
> (@ProbeName, @ProbeParams, @MethodEntry) and ProbeProviderInfo?
> 12) Section 4.5.1.2: Is there any risk with exposing remove method
> on TreeNode to 3rd parties? Should we have exposed only the
> integration point (example parentId)? See example at: http://wiki.glassfish.java.net/Wiki.jsp?page=GFV3PluggabilityOnePager#section-GFV3PluggabilityOnePager-4.1.1AdminConsole
> 13) Section 4.1.2.5: [Question] Example shows "gf:tx:*". Should the
> first tupple be "gf" in the example? How does this relate to DTrace?
> 14) Please clarify support for JVM, JDBC, JPA, jRubby monitoring and
> CallFlow support.
>
>
> --
> Nazrul Islam - (408) 276-6468 - Sun Microsystems, Inc.