Leif Mortenson wrote:
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
What do you have in mind here?
Fortress does not make all that much direct use of the IM. But I had been much more
involved with the ECM development and the InstrumentManager is fully integrated.
If you have tried it with Cocoon, you will see how useful that can be. You can see
information about how many times components are looked up and released over time.
How pools grow and shrink, as well as any blocking that may or may not take place.
If integrated at this level, the user of the container can get a huge benefit from
Instrumentation without ever making use of the API themselves.
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)
This is already in there. The AltRMI / HTTP / none connector system is entirely
configurable at runtime. See below. Additional connectors (transports) can easily
be added to the InstrumentManager code, or created externally as part of user
code. The later of course does not require any modification to the IM jar.
* assurance that we can tie in with JMX with or without
full functionality
Should be no problem. See below.
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)
I must apologize to having almost no knowledge of Merlin at this point. I have
started taking a look at it a few times, but under schedule crunches, I have always
been forced back to what I already know. Mainly Fortress.
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.
The AltRMI dependency is only at build time. There is absolutely no dependency on
AltRMI if that connector is not configured in the instrument manager's configuration
file. Currently, the AltRMI connector is only being used by the Instrument client
package. The HTTP connector currently is capable of serving either human readable
HTML or XML content. My original thought here was to replace AltRMI with XML
as the transport used by the instrument client. If that was done then I would have no
problem removing the AltRMI connector completely. I have not heard of anyone
making any other use of it. The work is done in the HTTP connector, but the client
side of the job has not been started.
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.
The easiest way to do this would be to create a new package:
org.apache.excalibur.instrument.manager.jmx
which contained an MBean that would be registered with the instrument manager
as a Connector.
Connectors can be registered in the instrument manager's configuration file using
the following xml:
<connectors>
<connector class="altrmi" port="15555"/>
<connector class="http" port="15080"/>
<connector class="com.myco.myapp.CustomConnector" myconf="myval"/>
</connectors>
The altrmi and http "class"s are special cases to make it easier for the user. But
any class can be specified as long as it implements the InstrumentManagerConnector
interface. The IM will treat them as Avalon components making
sure that they are started, stopped, configured. etc. An instrument manager instance
is passed to them using the InstrumentManagerConnector.setInstrumentManager
method. At that point, any method of the DefaultInstrumentManager class can be
called.
The IM will then shutdown any connectors that it initialized as part of its own
shutdown.
It is also possible to create and manage your own "connector" as a standard object.
If you give it a DefaultInstrumentManager instance then you can do with it as you
wish. The connector system simply makes it easy for the user to configure things
within the Instrument Manager's configuration file.
Long answer, but no, I don't see any problems with being able to hook things into
the JMX architecture other than that I don't think it is possible to make all of the
information collected by the Wrapper available in an easily viewable format using
JMX clients. Correct me if I am wrong. You could definitely publish things like
the latest values of individual instruments etc.
As for making the Instrument and InstrumentManager packages releasable. They
are very stable. I have been using them in production environments for quite some
time. The problem is the obvious lack of documentation. As you can see from the
Java Service Wrapper project, writing documentation does not give me a rash or
anything. But my schedule the last year has not given me any time to write up the
instrument docs, or do much other Avalon coding as of late. I will try to get at
least the basics written up though... It is a great tool.. But I can't blame anyone
for not using it without docs. :-/
Cheers, Leif
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
