geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Damon E. Sorrentino" <...@idearesources.com>
Subject Re: Component Tracing Service
Date Fri, 08 Aug 2003 21:32:24 GMT
The way it is non-intrusive in WAS 5.0 is you have to specifically 
enable tracing inside the application server. Once you do that, you 
then enable the tracing on the various components.

With tracing enabled, it then produces it's own log file called 
"tracing.log", or whatever name you want to call it.

You could either have it configurable through an admin console or 
configurable through editing raw XML configuration documents, whichever 
the user prefers. You could also have some command line shell 
environment that enables you to switch on/off configuration variables 
on the fly. That way things configurations can be scripted.

-damon

On Friday, August 8, 2003, at 04:19  PM, Robert McIntosh wrote:

> Now, if the J2EE container used this (or a similiar) system in a 
> non-intrusive way, say via interceptors ala JBoss, that would be 
> really nice. You could have the turn on/off feature and not have to 
> implement or extend any classes/interfaces. Would make a nice addition 
> to an admin console as well.
>
> Robert
>
> Berin Loritsch wrote:
>
>> Damon E. Sorrentino wrote:
>>
>>> One thing WebSphere 5.0 supports is a diagnostic tracing service 
>>> that administrators and developers can enable or disable at the 
>>> component level. For example, WebSphere has an HTTP_Transport 
>>> component with several public classes:
>>>
>>> com.ibm.ws.http.ChunkedInputStream
>>> com.ibm.ws.http.ContentLengthInputStream
>>> com.ibm.ws.http.HttpConnection
>>> com.ibm.ws.http.HttpRequest
>>> com.ibm.ws.http.HttpResponse
>>> .
>>> .
>>> .
>>
>>
>> I'm not sure if this is necessarily related, but Avalon has an API 
>> available
>> to instrument your code.  It is quite configurable and works pretty 
>> well.
>> THe instrument APIs provide (1) a way to extend your code to expose 
>> runtime
>> values, (2) a way to publish those (inside the same VM, or even 
>> outside if
>> desired), and (3) a way to view the instrumentation.  The client is a 
>> Java
>> Swing based app that provides some really nice meters.
>>
>> Another benefit besides just seeing the runtime state of your server 
>> is
>> also being able to tell the VM to do a garbage collection cycle.  The 
>> client
>> runs in its own JVM, and uses AltRMI to talk to the container code.
>>
>> Best benefit of all:
>>
>> Regardless of whether you choose to use Avalon for your container 
>> needs,
>> you can still use the instrumentation code.  The Avalon containers 
>> make it
>> a little easier because they are already integrated, but it is still 
>> an
>> extension.
>>
>> Its pretty cool stuff, and it is pretty useful.  Leif Mortenson is the
>> brainstormer behind it, and I have found him to be a rocket scientist
>> in regards to Java memory management.  Not even the GUI client leaks
>> memory!
>>
>> You can turn on and off the types of instruments you want to watch.
>>
>>>
>>> The administrator or developer can then enable certain types of 
>>> tracing within each class, i.e. entry/exit, event, and debug traces, 
>>> through their administration console web application. You can enable 
>>> any combination of these trace types.
>>>
>>> This type of functionality proves useful when trying to run 
>>> different J2EE applications inside multiple application servers.
>>>
>>> -damon
>>>
>>>
>>>
>>
>>
>


Mime
View raw message