Stephen, At your request, moving this discussion to the dev list.
Thanks.
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.
Thinking along similar lines. In my head is the instrumentation API as a potential reference point concerning the instrumentation abstraction relative to the composition and activation frameworks. This in turn could be augmented by leveraging instrumented thread and pool facilities in excalibur. Using facilities, we could add in the instrumentation event transport solution - e.g. a JMX RMI adapter, IIOP, AltRMI or the existing HTTP connection facilities you have in place.
There is one subject that I want to address:
* instrumentation of the composition and activation packages
There are two fundamental issues in this equation:
* no lock in on a particular transport (i.e. transport is
totally configurable and released, standards based solutions
can be put in place)
* assurance that we can tie in with JMX with or without
full functionalityAnd one open subject:
* some logic with respect to the synchronization of a management
model with an instrumentation model (keeping in mind that the
management connector model in Merlin is still in evolution)Father than reinvent stuff - I would rather work with solutions that exist and have been through real usage. The counter argument is the question of another dependency. Today the instrumentation package ties me into AltRMI which ties me into a legacy Avalon. This would need to be cleaned up. Basically - AltRMI has to be removed from the equation so long as it is in Incubator. Furthermore - I thing we need to come
with the Instrumentation/JMX bridge to make this work. If this is technically and politically viable - then there is a something to work with. Can you give me you opinions on this. Just for reference - if we can establish a releasable instrumentation package, I'm keen to collaborate on a solution here.
Cheers, Stephen.
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]
--
|------------------------------------------------| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org/merlin | | http://dpml.net/merlin/distributions/latest | |------------------------------------------------|
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
