Peter Donald wrote: > > 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 ?
http://www.joopmag.com/html/from_pages/article.asp?id=5121&mon=10&yr=2001 P.S. JOOP only publishes on the web SOME of the articles. > > 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. This is true. That is why the system has to be done in such a manner that when the client is connected, it receives all the messages. When the client is not connected, the messages must be destroyed--or even better never sent. > > 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. Yes, and the DBC tool I suggested would be decent--but it does incur a heavy run-time price when it is engaged. The DBC tool would only be used during validation and verification of the component. Again, DBC does require some important constraints. For instance, we would want it applied to the work interface so that the Component implementation can be verified according to the known contracts surrounding that interface. The thing that DBC cannot offer us is testing degradation of the Component's stability or performance over time. This is a different type of tracking. > > 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. The tracking systems outlined in the JOOP article had a 40% overhead accross the board. I consider that a very heavy cost. There was a nice little table to explain the problem domain. The meat of the table follows: Tracking | Framework-Based | Automatic Code | Automatic Component Aspects | Code Insertion | Insertion | Wrapping ----------------+-----------------+----------------+-------------------- Source Code | Needed | Needed | Not Needed ----------------+-----------------+----------------+-------------------- Code Separation | No | No | Yes ----------------+-----------------+----------------+-------------------- Overhead | High | Low | Low ----------------+-----------------+----------------+-------------------- Complexity | Low | Very High | High ----------------+-----------------+----------------+-------------------- Flexibility | High | Low | Low ----------------+-----------------+----------------+-------------------- Applicability | All types | OP trace, | OP trace, | | Perf. trace | Perf. tracec ----------------+-----------------+----------------+-------------------- Applicable | In-house | In-house | In-house and COTS Components | | | OP trace - Operational Trace Perf. trace - Performance trace COTS - Commercial Off-The-Shelf There is a list of different trace types: * Operational Trace: Records the intractions of component operations such as function invocations. It can be broken down into Internal and External function traces (invocations of methods internal to the component and external to the component). * Performance Trace: Records the performance data and benchmarks for each function of a component in a given platform and environment. * State Trace: Tracks the object states or data states in a component. * Event Trace: Records the events and sequences occuring in a component. * Error Trace: Records the error messages generated by a component. * Meta Information Trace: Tracks meta information about the component. This is used to expose size information (i.e. memory consumed, diskspace used, pool sizes, etc.). This is also not in the article. Here is a quick table I threw together that shows where I think the trace types are more important: Trace Type | Development | Verification | System | Operators | Trouble- | Production | and Testing | & Evaluation | Tuning | | Shooting | --------------+-------------+--------------+--------+-----------+----------+----------- Operational | * | * | | | * | --------------+-------------+--------------+--------+-----------+----------+----------- Performance | * | * | * | * | * | --------------+-------------+--------------+--------+-----------+----------+----------- State Trace | * | * | | * | * | --------------+-------------+--------------+--------+-----------+----------+----------- Event Trace | * | * | | | * | --------------+-------------+--------------+--------+-----------+----------+----------- Error Trace | * | * | | * | * | * --------------+-------------+--------------+--------+-----------+----------+----------- Meta Info | * | * | * | * | * | - (*) Useful (-) Sometimes useful ( ) Not necessary As you can see, not all types of tracing need to be used all the time. It would be good to remove the overhead of the unneeded tracing when you don't need it. A solution similar to the LogKit mechanism would be excellent as it can help you optimize out your trace types when no client is connected. It can also automatically re-enable the trace types when a client is accepting different kinds of traces. Part of the reason I meantioned AspectJ is that it can do the Operational tracing for Components we have no control over. By adding a tracking package to Framework, and an interface for a Tracer object, we can have another project work on the Tracer implementation. That way the mechanism to proliferate the tracing methods is a completely separate concern. We do have to manage how it is plugged in, but that is a later concern. > > 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. See my refinement above. It does take into account your comments. > > 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. This can be agent dependant. > > 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). Keep in mind that we want to expose the ability to Component writers. The Tracer implemented in Phoenix should most definitely be implemented with JMX. Especially since we started the work with it already. However, there are different clients with different needs. For example, Cocoon would like a mechanism so that when someone goes to the Cocoon Status page, they would like to have cache sizes and pool sizes included. With a generic Tracer interface, Cocoon can have a Tracer implementation that feeds the StatusGenerator with the information it want's to expose. It would even be able to add in performance data to find bottlenecks. > > 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 ;) Most people haven't. It is because the message information is not structured enough to do meaningful searches or categorizations of data. The Tracer implementation would be able to provide categorized events that are easily grouped and searchable. The client would even be able to provide meaningful summary information based on the samples it got. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
