geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul McMahan <>
Subject Re: [DISCUSS] Improving diagnostics
Date Thu, 14 Jun 2007 14:51:12 GMT
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,

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