Debugging Tip #1 - Using tcpdump / windump to figure out what's going on...

We had a problem today...

A bit of background - we build the Fast Suite on JDK 1.1 ... We chose it, because after many many years, the jre's are rock solid, so our server will stay up for months, and the small size of the jre keeps our download size down...

In JDK 1.1 land, when you're using sql PreparedStatements, with logging turned on, there's no way to see what the actual sql is that is being sent to the database... So we're getting a funny error from Oracle on some of our inserts... How to figure out what's going on?

A couple of options pop to mind... Using a proxy server - having FBT talk to the proxy, and the proxy in turn talk to the database... Quick to setup, captures everything - could be protocol issues, and when I tried it (without trying too hard) it didn't work for the Oracle protocol... Moving to option 2...

Option 2 is to use a packet sniffer to capture traffic between FBT and Oracle... Took about 15 minutes to download and install the tool on my machine and successfully capture what I was looking for... What did I do?

1) I'm on a Windows machine, so I used windump (the windows version of tcpdump...)

2) I messed around with the options, and used the following to get what I was looking for:

windump -i 2 -X -s 500 -w out.out port 1521

-i 2 = interface 2 (try windump -D to list interfaces and try other numbers if this doesn't work...)
-X - capture raw data
-s 500 - grab 500 bytes / packet (you might need to make this bigger for big sql commands...)
-w out.out - write the data to a file called out.out
port 1521 - only capture data on port 1521...

3) Then use FBT and generate the error...

4) Stop windump...

5) Check out the newly created file "out.out" - it will be full of binary info - but will also have raw text of SQL... I was able to find all of the sql between my machine and Oracle ...

Just a note that windump / tcpdump is a handy tool for examining / debugging / reverse engineering any networky type app... Running it on an unswitched network will allow you to basically capture all of the traffic on the network, to diagnose network slowdowns, etc... You could also be very evil with this tool... The primary ways to avoid losing data to a tool like this is to be on a switched network, use secure communication such as ssh or ssl ...

Another handy tool (in the Unix world) for figuring out what a 3rdparty library is doing, solving IO problems, etc is strace ... Not only allowing you to see network IO, but all IO (including disk IO), and any other kernel level calls within your system - want to generate megs of logs in no time at all - you need not look past strace...