Stephen, At your request, moving this discussion to the dev list.
As for JMX, one thing that could be done in certain situations is to create an MBean for
the instrument manager which would then act as a JMX Connector to the
InstrumentManager.
Currently AltRMI and HTTP Connectors exist. The AltRMI Connector exists which
allows you to connect to the IM using the Swing InstrumentClient.
The HTTP connector is not quite as convenient for letting you see more than one set
of sample history at a time (that can be changed). But it does have a lot of benefits
as well. Including the fact that you do not need a special client to connect. Any
browser will do. The connector can output either HTML or XML content so it
should be very easy to send the XML through Cocoon and transform the XML into
whatever other format you need.
Cheers, Leif
Stephen McConnell wrote:
Can you do me a favor and post the following extract of your email to [EMAIL PROTECTED]
My feeling is that there is a place where your work in instrumentation fits with aspects of JMX and the overall merlin architecture. There are a bunch of thoughts I have about this but they are better on-list than off.
Leif Mortenson wrote:
Basically I view the Instrument package as being completely different from JMX.
As I understand it, using JVM you would be able to make individual data points
available at any given time. But as I understand it, there is no way to build up
history or display the data points as they change over time.
When I created the Instrument code. I wanted to create a tool that would integrated
in a similar way as Logging is done. Instruments would be added throughout classes
just as debug log output is added. When not in use these instruments do not affect the
performance of the application. But at any time, a client can connect to the JVM and
request a snapshot of the instrument, or ask that the instrument start building up a
history.
These sample sets are requested using a lease system. Once the sample is requested
they will continue to be collected in the JVM even if the JVM is restarted and or the
client disconnects. It is then possible to connect at a later time, before the lease
expires, and see the instrument sample history that was built up. Both the HTTP
and instrument-client interfaces make it possible to view the sample history as a
graph. By comparing key instrument sample sets. It can be very easy to tell exactly
what is happening within an application.
I make use of instruments for everything from pool sizes, to keeping track of the
number of times that a certain servlet is called and then how long each call takes
to complete.
The instrument manager allows you to specify that certain instruments should have
permanent sample sets. These do not require a lease and are always available.
I usually use these to track memory usage, HTTP connection and access counts
and other data which I want to see over a long period of time.
Because the instrument data is preserved across JVM restarts, this makes it
possible to see how the memory usage of an application changes over several
months.
I really need to get it documented so it would be easy for you try out. I can
almost guarantee that once you understand the data that is collected you very
quickly find it as invaluable as logging. My customers all use the HTTP client
to connect to their applications and very quickly get a feel for the health of the
app. Memory leaks and resource problems are immediately obvious just by
glancing at the appropriate instrument sample graph.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
