Thursday, May 08, 2008

Advanced Enterprise Debugging Techniques - TS-6072

These are the tidied up notes I took from the session at the JavaOne 2008 conference in San Francisco, California. There may well be mistakes and ommissions. I will come back and correct them once the conference has completed. However my first priority is to get the information published before the backlog gets too large and swamps me. All comments welcome. Enjoy!

Neal Ford, Thoughtworks

Debugging 101
- Problem? Before you do anything else, step away from the computer and think. This is the hardest thing to learn

Forensic debugging with loggers
- Log4J
- Examine log4j's xml log files with Chainsaw (aSwing UI) which hacks up your log dumps. It allows filtering to look at particular log files post mortem
- You can create a genrator for Log4J which you can plug right into chainsaw which allows you to view running apps live (still with the filtering etc.)

Fiddling with your application in production? - Fiddle
- Ideally your debug (dev.) environment would like like production - but it never does
- But you don't want to turn on remote debugging in live
- There is an OSS app which allows you to fiddle with your app using scripting languages to find out what is going on in there in production
- Fiddle: A single jar file with no external dependencies which you drop into your app server
- Get it from
- It provides a fiddle executable servlet. You send it some scripting code which it will execute and display the output on the fiddle web page
- It also comes with fiddler - a text area where you type in the script
- fiddle-scripts - pre rolled fiddle scripts for you to use
- Your scripts can use groovy, javascript, jython (scripting so you don't need to compile.)
- e.g. get info from system tables, get the loader path, find out which xml parser is loaded, get all the system properties, you can even tweak security settings and get values out of HTTP sessions
- To use it, take the fiddle servlet, put it behind a password protected page, and use as required

Debugging back in time - Omniscient Debugger
- Takes regular snapshots when your app runs and saves them.
- Allows you to visit any snapshots in the past - i.e. run your app until it gets corrupted, then you go back in time to find out where things went wrong. It effectievly sprinkles breakpoints and allows you to go and use them
- Now you can walk through, one snapshot at a time. You can also walk backwards through the timestamps.
- All you need to tweak is how granular you want the snapshots. But you can make this pretty coarse grained and still see how things work
- Good for multithreaded problems
- It is a jar file and easy to run along with your application server
- N.b. it uses a lot of memory but can save you time in debugging

Untangling Jars - Jar Analyzer
- It's hard to look at a directory with all the jars and see what all the relationships between them are
- use jar analyzer
- It has a xml output (ugly but packed with data)
- Fortunately this comes with a XSL stylesheet => transformed to a nice page.
- Points out cyclic dependencies
- There is also a graphical view output which gives a Tree view. The problem is this can get really complicated. All it does is show you the mess
- Commercial alternatives? - SonarJ. The Spring project used this to make sure they didn't get into such a mess. Now they use Structure101
- Step one is knowing that a mess exists. Then you can fix it by hand or use one of these tools

Mocks for Faster Debugging - MockRunner
- There are multiple testing levels: unit (simple, single component - my thing works like I think it does), functional (my stuff works with their stuff if their stuff isn't there yet - mocking. I can also mock out parts of J2EE), integration (major chunks talking to one another - my stuff and their stuff works together) and user acceptance
- To speed up functional tests you want a Mocking infrastructure (e.g. MockRunner to mock J2EE infrastrcture). You use it to ceate a test fixture (harness). This then rnus the tests using regular JMock tests
- Now it is almost instantaneous to run your tests. An example is to mock out JMS with thread pools. You can also do this with Servlets, EJB, and all the other interesting parts of J2EE
- Great time gains

Automating UAT - Selenium
- Use this to automate tests which run against your running web app for UAT
- It can also be used to automate tedious debugging tasks
- It includes a side project called Selenium IDE to record tests
- This allows you to automate debugging "wizard" style web applications and removes the hassle of manually stepping through the bits you have working to the broken bit in wizards
- Because you always think "this is the last time I have to do this" but it never is
- You don't even need Selenium installed to do it; it's a Firefox plugin. You can record your interactions with a web site and play it back automatically
- There are single step and pause buttons in Selenium IDE for stepping through
- All you do is record an interaction the first time you do it manually
- When you record your steps, it is stored as an HTML table. This looks like a fit test
- You can export this table to java - this is then a regular JUnit test case which you can run standalone
- You can also export as Ruby, Python, Perl and other languages
- Basically it's an interation API for a web browser/applications - you could even create a black box for web browsers (i.e. in airplanes) to track what users are doing.
- You could also get your QA dept to record their tests so they can send you the script which breaks the app
- What if I want to run in IE? => use Selenium remote control. I don't want to deploy parts of Selenuim to a production application. SRC creates a proxy server (flavour of jetty) which the test runs against which in turn runs against the real server by spawning a new instance of a browser. There is no selenium on the production server. You can tell it to launch IE, or some other browser.
- You can have a headless server which kicks off many different types of test clients and kick this off from your CI server

No comments: