While checking my disk space at work I was surprised to see that my .mozilla-thunderbird was whopping 30 GB. Since I received many mails during the day – some being system monitoring mails – I was keeping all of them. This helped me most of the times since I can check the state of the system over a give period of time.
So I decided to spent some time and find out which of my local mail folders are having what size. With simple linux/unix command du -h –max-depth=1 ~/.mozilla-thunderbird, I figured out that there was a filterlog.html file under my mozilla profile which was around 26GB. Tailing the file I found that it had log messages for every mail that was filtered from my INBOX to local folders.
I do not know if this was a default setting or I did it by mistake. But for whatever reason I did not need this log. So in order to get rid of such message I went to Tools -> Message Filters and for my inbox folder and disabled the FilterLog.
Recently while tracking down a weird behavior in my application, SQL traces and MaxDB kernel traces were very useful. This issue is described in my other post here. So I thought I would share my experience with others those that would fall in similar trap.
When you execute any SQL from with a java program your java program acts as a client to the database. In case of MaxDB JDBC driver the SQL traces can be collected at the client side (i.e on your java application side) and the kernel traces on server (i.e. the database side).
SQL Traces
In order to switch on SQL trace for MaxDB JDBC driver you need to locate sapdbc.jar that your java application will use to execute SQL queries on MAxDB database. Launch GUI application with
java -jar sapdbc.jar
or
double click on sapdbc.jar which will also launch GUI application since it is an executable jar. Make sure that java is in your path.
Similar to:
sql trace
Then check “Tracing enabled” checkbox, select the trace file folder and hit OK. This would switch on SQL traces on the client side. You may want to switch on kernel trace (explained below) before running your application. After you run your application that executes a SQL it would generate jdbctrace.prt in the speified location, in above example it is d:\temp. jdbctrace.prt is a text file which can be viewed by any text editor. Make sure that you run this configuration GUI with the same user that will execute your java program.
Kernel traces
To switch on kernel traces first locate the MaxDB database installation directory. Open a shell/console and then go to <maxdb-installation-home>\programs\pgm and execute
dbmcli -u <admin-user> -d <database-name>
Then on dbmcli console execute
Util_execute diagnose vtrace clear
Util_execute diagnose vtrace default on
->run your program
Trace_flush
Util_execute diagnose vtrace default off
Trace_prot msakbe
Then the trace would be written to MaxDBs rundirectory ...\wrk\<database-name>\<database-name>.prt
With new kernel version MaxDB 7.7 is complaint with JDBC driver specification. Due to this change (or lets say correction from MaxDB ) my application running perfectly fine with MaxDb 7.6 was not running properly with MaxDB 7.7 kernel and the new JDBC driver.
In fact my application was using the misbehavior designed in previous versions of MAxDB. Method ResultSetMetaData.getCoulmnName was returning the label/alias defined in SQL rather than the column name defined in the table. My result set parsing algorithm was based on the label/alias defined in SQL which was fetched by ResultSetMetaData.getCoulmnName. Since this has been corrected in MaxDB 7.7 my algorithm did not work as expected as the method call ResultSetMetaData.getCoulmnName gave me the column name (which is the correct behavior). To fix my parser I had to call ResultSetMetaData.getLabelName to get the alias/label defined in SQL.
For example, if the query is:
SELECT X AS Y FROM DUAL
With MaxDB 7.6 ResultSetMetaData.getCoulmnName(1) returned "Y" while MaxDB 7.7 returned "X".
When your java application stalls/hangs due to a deadlock you want to get a thread dump. Normally you hit ctrl+break under windows (you hit this on the console) and send signal “kill -3″ to the process under nix systems.
Under windows if you are running your java application as a service or is launched from within an IDE (ItelliJ, Eclipse, etc.) you may not have console. You are struck with the deadlock but it may be hard to reproduce. Fortunately there is way out. Thanks to the StackTrace application. I found this application very useful and I can recommend every java developer to use this in such or many other situations.
StackTrace is free to use if you use it via java web start. Here are the steps to launch it.
SAP NetWeaver 6.4 runs with java 1.4. In order deploy my application that was built in java 1.5 on SAP NW 6.4 I needed to first compile it “-target” option from java compile “javac”. So I tried following ant build xml snippet:
One should keep in mind that you cannot replace new classes from java 1.5 with this technique. If possible you can provide additional jars that work with 1.4 (For e.g. classes from javax.management.* package).
While scanning through my log files I spotted “SAP DBTech JDBC: Cannot connect to jdbc:sapdb://maxdb/testdb [Cannot connect to host maxdb [no route to host: connect], -813]”. But my application was running normal. I didn’t know if this was any abnormal behavior in my application.
Fortunately I had a break point at the point where the SQLException was raised. And at the same time I could not see my network share. Reason was that my network cable was loose and it kicked my pc in and out of the LAN. It was obvious enough that when my pc was temporarily not connected to the LAN, my application was executing sql query and it could not find the host where my maxdb database was running.
Sometimes you need to be lucky to find the cause of an error .
SAP NetWeaver 6.4 run with the old version of javax.naming.QName class. You need to first get the version that works with XFire 1.2.3/1.2.6. You can download it from here http://xfire.codehaus.org/FAQ. There are several ways to force SAP NW use latest QName, but I will choose the simplest one, prepending to the java booth classpath using -Xbootclasspath/p option.
For e.g -Xbootclasspath/p:c:\lib\QName.jar
This is not just sufficient to get XFire client working against web service running on SAP NW. It
seems that the SAP NetWeaver 6.4 does not implement the HTTP protocol feature ‘Expect: 100-continue’ properly. XFire uses http-client internally to make http connections. By default XFire uses ‘Expect: 100-continue’ feature from HTTP/1.1. When XFire executes any web service on SAP NW 6.4 it sends http request which includes an Expect request-header field with the “100-continue” expectation. SAP NW then responds with 100 (Continue) status. XFire now sends the request body and expects the final status code 200. But SAP NW sends http response with the header ‘\u000HTTP 200 OK’. This is an invalid http response since it contains null byte at the beginning. To avoid this you need disable ‘Expect: 100-continue’ by setting http.protocol.expect-continue=false parameter on http client used by XFire.
.
