avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: instrumentation and other questions
Date Fri, 26 Mar 2004 01:36:06 GMT
Leif Mortenson wrote:

> 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 functionality

And 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 
>> dev@avalon?
>>
>> 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: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
> 
> 


-- 

|------------------------------------------------|
| Magic by Merlin                                |
| Production by Avalon                           |
|                                                |
| http://avalon.apache.org/merlin                |
| http://dpml.net/merlin/distributions/latest    |
|------------------------------------------------|

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Mime
View raw message