Debugging Techniques

Log Entries and Println

What is the best way to go about debugging a running sakai install? I've currently been adding logging messages to the code to determine some of the pathways through it, but I can't belive that the whole thing was built using just logging. I'm open for suggestions as I don't have a ton of experience in larger scale JSP apps.

JSWAT

I like to debug Sakai by running a local (or remote) tomcat with Sakai, and having the source on my development machine, along with jswat, an open source java debugger. I run tomcat in jpda mode (catalina jpda start), connect to the local or remote tomcat from jswat, and away I go. This is especially cool to do with tomcat running on a remote server.

http://www.bluemarsh.com/java/jswat/

Eclipse Enterprise Debug Perspective

Another option for debugging Sakai is running Sakai in Tomcat in jpda mode connected, in my case, to a local copy of MySQL and using the MyEclipse Enterprise workbench in a Debug perspective, setting breakpoints as necessary while I step through the code.

To review a list of supported features see:

http://www.myeclipseide.com/ContentExpress-display-ceid-15.html

It works with regular eclipse (3.0) too.

Ant and Eclipse

When I inherited CourseWork I had the same problem. After a day or two of trying to incorporate lots of oral history about the code I punted and loaded it into an IDE. Regular Eclipse was free, and that's the track I took.

After that it was all forensic work - breakpoints, logs and a database query tool.

My current practice is to develop on my laptop with a full service stack (oracle/Coursework/tomcat) in eclipse, using the Eclipse tomcat plugin. (having the full service stack on the laptop is quite handy for skipping out of the office and working somewhere exotic like at a SEPP meeting). (it is also handy for testing robustness of the app; you can shut down
your database and no one cares.)

I then do an Ant deploy of CourseWork to Solaris (partial service stack there; remote oracle) and if need be use the jpda mode and the same code base on my desktop machine.

If that passes muster I do a deploy of CourseWork to the common Solaris QA instance and do the same if QA reports something odd.

I am full of hope that this practice will be transferable to my Sakai deployment/development effort, just with Maven in the mix as opposed to Ant.

Oh I still have lots of logging going on -casey

(later on)

This technique has worked fine for S1.5; I've deployed it to my primary development machine (lowly dell laptop) and used JPDA to trace code as it runs. Builds w/Maven are no problem. It's not as sexy as managing everything via the Tomcat plugin in Eclipse, but that's fine. I expect it to work well for 2.x too.

The stumbling block was in hacking up the tomcat.bat file to switch away from the shared memory connection mode and to assign a port. Once I switched over to using cygwin to launch the tomcat using the unix shell scripts that became moot. I was even able to do sensible things like tail -f, find . | xargs grep foo, blah blah blah.

(still later on)

this has continued to be useful through 2.3.x. Most of the complexity has arisen from from my Employer's constant switching of reference platforms ("You must use Solaris8, or 10, er, 8, except that now its the local custom Linux, er, Dell 2kServer, no, Debian, or Redhat yes Redhat") and the impact on all the downstream software.

currently my development env is OS X, with parallel dev envs on Solaris 8, Cygwin, Debian and Redhat. QA is using Solaris and Redhat, while production is Solaris 8 with a scheduled transition to Redhat. unless political turf wars take us back to Solaris or Debian. (remember, S.U.N. comes from Stanford University Network, so it's all political)

It boils down to these steps:

reproducible builds in all envs (OS) and contexts ( dev, qa, preprod )
writing code for testing code
using whatever you can of jUnit and the Sakai test harness you can before you do an integrated build
logging
remote deubgging via JPDA

casey dunn

Java Memory Leaks

Use the following java options to cause garbage collection times to be displayed in the console:

JAVA_OPTS="-server -Xms1g -Xmx1g -XX:NewRatio=2 -verbose:gc -XX: +PrintGCDetails -XX:+PrintGCTimeStamps"