geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jay D. McHugh" <>
Subject Re: [DISCUSS] Improving diagnostics
Date Thu, 14 Jun 2007 16:10:24 GMT
Is there anyway we could intercept when exceptions are created?  If we 
could then one possibility to improve diagnostics would be to keep a 
count of what exceptions are being thrown and from where.  With that 
information, we could perhaps give an administrator hints on where 
trouble spots are in their applications.  Or, we could automatically 
escalate the level of logging/information provided in areas that throw 
lots of exceptions (subject to some user configured threshold).

And regarding XML serialization - Does anyone know where the XML 
serialization work was done or who did it (if there really was any work 
on this)?

I am trying to rework some of the console screens to get better browser 
compatibility and sending information back and forth in XML will prevent 
some javascript security problems.

If someone has already figured out the schema to describe GBeans then 
that would make my work on the console easier too.


Paul McMahan wrote:
> I like your ideas!  Thanks for bringing up this important topic.  One 
> of my pet peeves in debugging geronimo apps is when I'm trying to step 
> through a gbean call but the debugger doesn't have the source 
> available since cglib has dynamically generated the proxy classes.  I 
> usually end up having to do cheesy things like setting breakpoints on 
> both sides of the proxy, which only works if I can figure out what's 
> on the other side of the proxy.  Seems like I remember some talk a 
> while ago about an experimental runtime mode which disables proxying.  
> I don't think you would want to normally run in that mode but it would 
> be useful for debugging purposes.  I don't remember where that ended 
> up.   One other thing that I think would be very helpful for debug and 
> diagnostics would be to serialize gbean info to xml rather than a 
> serialized java object.   Again, I think there was some experimental 
> work on this a few months ago but where did it end up?  Maybe these 
> improvements are already and I just didn't know about it :-)
> Best wishes,
> Paul
> On Jun 14, 2007, at 9:08 AM, Matt Hogstrom wrote:
>> Lately I've been working with users in debugging various application 
>> problems.  Some of the problems are merely configuration but others 
>> are deeper application / infrastructure problems.  Regardless of the 
>> type of problem I've never personally been satisfied with the 
>> diagnostic information produced by the server (this isn't a Geronimo 
>> statement but really AppServers as a whole including WebSphere and 
>> WebLogic).
>> Here are some thoughts that I want to pursue:
>> I’ve been working with some customers lately and the work has 
>> centered around debugging some of the aspects of their server.  In 
>> this case it was using Apache Geronimo but the problem really applies 
>> to most application servers in general.  For the most part there is 
>> little diagnostic information available when an application fails.  
>> We get the ever popular nested Java Stack trace which is certainly a 
>> good indicator of where a failure occurred but is woefully inadequate 
>> in many instances of why a failure occurred.  This get’s worse in 
>> that for the most part people need to recreate the problem with 
>> additional tracing and, in the worst case, additional diagnostic code 
>> in their application.  Wouldn’t it be nice if some of the diagnostic 
>> capability that was needed was included in the server itself?
>> Over the next few weeks I’m going to be doing some experimentation on 
>> how to improve server diagnostics through the use of Aspects and/or 
>> Instrumentation.  Since this is experimental we’ll see what the final 
>> result will be.  Here are some of my initial goals:
>>    1.  Improve diagnostics by providing a Diagnostic Report when a Tx 
>> fails.
>>    2. Provide better visualization of Java Stack traces so problem 
>> areas pop out.
>>    3. Capture wait information
>> For number 1 I’m going to focus on servlets to begin with given that 
>> they represent the preponderance of requests made in AppServers 
>> today.  This information will include information from the request 
>> object, the servlet being invoked, invocation time, transaction ID 
>> (if it exists), enlisted connections (database and messaging), oh 
>> yeah, and the Thread ID of execution.  This is a mouthful to begin 
>> with anyway.
>> Number 2 is really just applying some template information on a Java 
>> Stack trace.  I want application classes to standout so developers 
>> will be able to quickly see where their application is involved.  
>> Infrastructure pieces like the server, Hibernate, TopLink, etc. would 
>> also be highlighted in a different color and style and plain old java 
>> classes would be a boring style as their are merely pawns in the 
>> transactional game.
>> Finally, wouldn’t it be nice to know how long a thread has been 
>> waiting and for what reason?  Is it waiting on a request from another 
>> server or perhaps there is a database locking problem.  Did a 
>> WebService go awry?  Basically, I want to know what in the heck a 
>> thread is waiting on.
>> Please chime in with your thoughts.  I spect that Aspects or 
>> Instrumentation may be the only way to go for some of this as many of 
>> the components we include won't have this capability in them.

View raw message