On Sat, 13 Oct 2001 02:27, Berin Loritsch wrote:
> I have been pondering for a while the process of exposing
> information during system debugging and tuning, but with
> minimal to no overhead during runtime. This is something
> that I have been thinking about for a few months now, and
> thanks to an article in "Jounal of Object Oriented
> Programming" (JOOP) I think I have a workable plan. The
> article in question is from the October/November 2001
> issue (Vol. 14, No. 4), "Tracking Software Components",
> pp. 13-22 written by Jerry Gao, Ph.D., Eugene Y. Zhu,
> and Simon Shim, Ph.D..
I don't suppose theres a Web ref for that ?
> With the bibliography out of the way, let me describe the
> problem: System administrators need the ability to tune
> Phoenix and Excalibur components but information such as
> pool sizes are well hidden, and Developers need
> authoritative debugging and tracing information so that
> they can be assured that everything is behaving as expected.
Operators also need tracing information usually for monitoring things etc.
> Run-time verification simply receives events for a Component
> that signify the Component is going through it's state/stage
> transitions according to the contracts. It should provide
> some sort of notification if there is a conflict. Unfortunately
> this type of tracking has an associated overhead with it.
> The overhead can be expensive as 40% or more depending on how
> much. For this type of tracking the only thing I can suggest
> with any type of confidence is AspectJ.
At one stage you also suggested a Design By Contract tool that allowed you to
force pre, post and immutable conditions. That could be useful if the system
was appropriately designed.
> This allows runtime
> aspects to be placed on a system. The type of checking is
> standard accross the board and it does not require embedding
> hand code in our components. It has the added benefit that
> the Aspects can be removed in the run time causing an increase
> in response times for the system.
I guess I have a different opinion on this. I think that most of the
monitoring and verification code adds such a minimal overhead but has such a
positive value that we shouldn't mind putting it in all the time.
In some cases we may want to limit the degree to which other aspects are
implemented. In these cases I would actually prefer not to use aspect J but
to implement something like the following strategy.
Almost all "join points" should occur via a java interface (I think). Thus in
JDK1.3 we can use the automatic proxy generation classes to add in approriate
protections and control.
For instance, say we wanted to debug a method to make sure it's pre/post
conditions were valid. We could add in an InvocationHandler that looks
something like
Object invoke( Object o, Method m, Object[] params, ....)
{
checkPreconditions( o, params );
try
{
return m.invoke( object, params );
}
finally
{
checkPostconditions( o, params );
}
}
Alternatively we could add in invocation handlers for almost any other use.
If there was some that we don't want to be applied in a production
system then we can just use normal interface rather than generating a proxy.
> 3) It is only exposed to an authorized client.
...snip...
> Challenge number 3 is more difficult to overcome. There has to
> be some sort of handshaking that needs to happen to authenticate
> and authorize a client. For this solution, dynamically generated
> magic keys might be an attractive solution. It is basically how
> X Windows servers authenticate clients. They have some sort of
> magic key value that is used as a shared secret. Again, this may
> be overthinking it a bit. We have to consider the type of
> information we would be publishing, and then determine if it is
> worth it. Another solution is blind trust in the installed jars,
> and implement the Jar services solution (requiring JDK 1.3+).
I think 3 is largely up to the object that wants to expose the management
information.
> Let me provide an example of possible information that would be
> shared with the administrator:
>
> * Pool size information--used to determine the most efficient
> pooling sizes for the particular pooled components or datasources.
>
> * Role to Component mapping--used to verify that the expected
> component is used for the role. By extension, this would apply
> to Blocks and Services as well.
>
> The first example is relatively harmless, but the second example
> provides a possible security hole. The problem here is that when
> a security hole is discovered in a Block or Component, you don't
> want to advertise that you are using it. While this is obscurity,
> and not security, it does minimize potential attacks until you
> are able to plug the hole. Again, getting back to the ability
> of exposing the information, when a security hole becomes known
> it would allow the administrator the ability to verify if they
> have the affected component or not. Hense we have a catch 22--
> Damned if we do, damned if we don't expose the info.
Again I think it is up to the management agent. Some may allow no one, except
those who pass retinal scans, dna fingerprinting and voice recognition while
others may simply require a HTTP password. It is completely dependent on
agent IMO.
> The demands for such a system are that there should only be one (1)
> client connected at a time,
I don't see this as a must.
> and that the client be known to the server.
> This does in effect rule out the Jar services approach. One practical
> requirement is that the client needs to be able to be detached from
> the server environment. JSSE does provide automatic handshaking so
> that would minimize the developer effort (I have implemented the client
> side of PKI sessions with Apache JMeter). That requirement would
> in turn require the messages to be sent in a structured and known
> format.
>
> Is this something that is worth the time pursuing? I think so, but
> it would have to be a community developed approach.
It is definetly something that we should be doing. However I believe it
should be built on JMX> While JMX may not be the most elegant API, it is a
standard and for 99% of time it is good-enough. (And I think we can get
around the licensing issues by reusing parts of enhydra).
I have started to write some base MBeans that make it easy to create
manageable objects (based on Leos work).
See jakarta-avalon-phoenix/src/java/org/apache/jmx/introspector/ for base
MBean objects. They can either be used to auotmagically generate MBeans from
an object, or set of interfaces or programatically. See
org.apache.avalon.phoenix.components.kernel.DefaultKernelMBean for example of
programatic management. In the future I also want to allow creation of MBeans
based on a descriptor that sits besides component.
However the part we are missing is the agent. If you start up phoenix using
--remote-manager you will be able to see the extremely simplified management
interface via an unauthenticated webserver (See System.out for port number).
In time I hope to replace the WebServer agent with something that is less
encmbered by licensing restrictions and more secure/useful/freely licensed.
However that sounds exactly what you want to do - so I could quite easily let
you play with it ? ;)
So I think that once we have a good agent and we have added decent MBeans for
objects all should be good. I tend to prefer to do it programatically rather
than via AspectJ though ;)
> Keep in mind that Logging, while vital, does not necessarily provide
> the functionality we are looking for. It also does not allow us to
> isolate a specific class of information for quick retrieval and Ad
> Hoc querrying.
I classify logging as a subset of the notification information provided in
JMX. I hadn't thought of using logging files as a searchable data store
though ;)
--
Cheers,
Pete
"The ability to quote is a serviceable substitute for wit." -- Maugham
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
