Prasenjeet Dutta (giskard at myrealbox com)
What's wrong with this servlet? (It connects to a SQL Server 2000 database using its Type 4 JDBC drivers, executes a query, and spits out XML while iterating over the resulting ResultSet.)
Actually, not much. On a Win2000 box with Tomcat 4.0 and JRE 1.4.0-b92, it spat out large (4k-7k records) ResultSets within decent spans of time. Ditto for small recordsets on Linux (RedHat 7.3, Tomcat 4.0 and JRE 1.4.0_01-b03). But on larger recordsets in the 4k-7k range, things began to fall apart: 116,862ms for 1100 records.
Worse, the fall-apart would not happen to everyone. It would happen only to this poor hapless reader program (also written in Java) running on the same Linux box. (This program generated the statistic of 116,862ms for 1100 records, noted above.)
Back down on Windows, the same reader program's classfile would chug along fine at just above 1500ms for 1100 records. And back on Linux, good ol' wget and GET fetched the servlet's xml quickly, much quicker than the reader program in fact (since they didn't have to parse their input).
Obviously something was blocking while doing I/O, but only when the servlet and the reader program interacted on Linux. A quick java -prof (of a key routine) seems to bear me out:
This one's the reader program running on Windows. Seems fairly innocuous.
This one's the reader program running on Linux. Look at the wait()s. 3
calls apiece, but significant amounts of time spent.
Is there a Linux/Java guru who can shed some light on this? I would have strongly suspected a SQL Server driver issue if other clients hadn't been able to get results quickly. I wonder if this problem will repeat with Oracle and DB/2. Ah, java, java: write once, debug anywhere ;-).