Hi,
Please find my comments below:
section #2.1:
----------------
I don't see why we should write a tool that can be used by a wide
variety of Java applications. Surely, application server will be one of
the primary users of such a tool, but not the only one. This
infrastructure should be be provided by underlying platform, which in
our case is JDK.
section #2.2:
----------------
Since JDK 6 is the minimum platform, I can't see how this can satisfy
needs of V3 Prelude, which is anticipated to be used in JDK 5 more often
than not. Pl. correct me if I am wrong here.
section #3.1:
---------------
Is there not a need to monitor a cluster of application server
instances? btrace allows this.
section #4.1.1:
------------------
What happens when some other parts of runtime tries to insert
ClassFileTransformer? e.g., JPA implementations are known to do so.
section #4.1.1:
------------------
It says
/Application server would be the right product to build this
intelligence of generating the lightweight data in production
environment and analysing them to present it in a meaningful way, so the
administrators can get to the root cause of the problem./
Can you please describe how you achieve *zero* overhead when the code
has been statically instrumented to emit events as described in section
#4.1.1.5?
section #4.1.1.15:
-----------------------
It says
/This means that there is no client here./
This is incorrect. There is a client API for BTrace -- is used by
command line client and VisualVM client. In a private email
conversation, btrace author, Sundar
(
http://blogs.sun.com/sundararajan/), has confirmed that a JMX cover is
being planned. He says:
/BTrace author can annotate a bit more in trace class so that the trace
class
registers itself as a MXBean. Specially annotated fields will be exposed
as MXBean attributes. This way any JMX client can consume trace data.
/
/i.e., something like
@BTrace(MBean="com.acme.MyBean")
public class X {
@Attribute(name="cacheSize")
private static int i;
// i is updated from various action methods of various probes
}
/
section #4.1.1.15:
----------------------
It says
/Also, the set of operations that a Btrace client can perform is also
limited./
It is fairly simple to relax BTrace strictness. Sundar says they need to
change BTrace code in just two places. If desired, we can allow
restricted method calls [say calls to specific Sun classes only].
How to write higher level probes (rather than trace author using
internal code names which would be unstable) using btrace? It is given
below:
/BTrace allows one or more probe descriptors be written. The probe
descriptors map abstract provide/probe name to concrete class/method (or
some other concrete probes).
This way trace author can write trace code that is "stable". For
example, see "$BTRACE/samples/SocketTracker1.java". The probe
descriptor file is $BTRACE/samples/java.net.Socket.xml
This file maps JDK's internal class/method names to higher level
provide/probe names. This method is better compared to doing code
changes to traced code. i.e., DTrace expects traced program
authors to insert macros in their code. While that approach is okay for
C/C++ world, for java world any code change in traced program just for
observability is undesirable. Even a simple "event
out" method will be a cost. The XML mapping scheme removes that
disadvantage. You may want probe points at specific locations which may
not be expressible as BTrace probe points. Even in
such cases it is possible to call an empty static method from a class --
which can be instrumented by BTrace. The empty methods are inlined and
optimized away by hotspot and other VMs anyway.
[whereas event firing methods may not optimized that way].
/
This makes me feel btrace is the right infrastructure to base v3's
monitoring solution on. There are people already btrace and there are
already external contribution to it as the following links show:
http://blogs.sun.com/sundararajan/entry/btrace_in_real_world
http://blogs.sun.com/sundararajan/entry/btrace_aggregations_contribution_from_community
http://blog.igorminar.com/2008/06/btrace-dtrace-for-java.html
Thanks,
Sahoo
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
>
> Feedback/review period ends this Friday.
> Any comments received after that would not be considered for this
> release.
>
> thanks
> v3 Monitoring team
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>