P2
OPERATING SYSTEM(S):
Windows XP SP2
FULL JDK VERSION(S):
1.5.0_13
1.6.0_03
DESCRIPTION:
We are seeing a problem with the Java Plugin when running IBM's DB2 Content Manager (CM) eClient applet.
The problem we are facing is that intermittently and without any consistency to it, they get an 'Unable to open selected document' error (Screenshot in JavaVersion_1_5_08.JPG).
The error is reproduced by, rapidly opening documents returned as results of a search, one after the other, by clicking on each document icon on the results page (Screenshot in Results.jpg), to view it in the eClient's viewer applet. The viewer applet requires the Java plugin to run.
eClient Support and CM Support thorougly investigated this issue using traces of all the DB2 Content Manager layers that are involved in the retrieval of the document and none of the CM component traces showed any problem with retrieving the document into the browser. Since the documents are being viewed in the eClient viewer applet which uses the Java plugin to run, eClient Support had the customer capture
a Java console trace of using JRE 1.5.0_08 which showed a java.net.SocketTimeoutException:
java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(Unknown Source)
at java.io.BufferedInputStream.fill(Unknown Source)
at java.io.BufferedInputStream.read1(Unknown Source)
at java.io.BufferedInputStream.read(Unknown Source)
at sun.net.www.http.HttpClient.parseHTTPHeader(Unknown Source)
at sun.net.www.http.HttpClient.parseHTTP(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
at com.ibm.idm.applet.IDMViewerApplet.loadDocument(IDMViewerApplet.java:1352)
at com.ibm.idm.applet.IDMViewerApplet.run(IDMViewerApplet.java:635)
at java.lang.Thread.run(Unknown Source)
We are using default settings for the plugin and JRE 1.5.0_08 has infinite readtimeout and connectiontimeout as the default values. Therefore it is very strange that the read time out errors are occuring with the default values of infinite read and connection timeouts.
An Ethereal network packet trace was then captured (Test_Ethereal.cap) while reproducing the error, to further isolate the problem as the next step. The packet trace shows communication between IHS|Websphere side (10.15.101.131) and the eClient side (172.20.73.151).
At this stage, the issue was transferred to IBM HTTP Server Support, who found an error in the handshake between eClient side and the HTTP Server side signals, in the network packet trace. Specifically, they noticed that the eClient side of the connection issued a premature RST as the packet trace in Test_Ethereal.cap clearly shows.
On one connection the eclient sends a POST to IHS and then sends a FIN, ACK indicating it's done sending data to IHS. The web server then responds to eclient with an ACK and then another ACK and then the 200 response. But then the eclient appears to prematurely send a RST, ACK before the web server had sent the FIN, ACK indicating it was done sending data. The Filter to isolate the packets for this erroneous handshake is: (ip.addr eq 172.20.73.151 and ip.addr eq 10.15.101.131) and (tcp.port eq 1910 and tcp.port eq 80)
A normal handshake would require that the eclient machine should have issued an ACK to acknowledge it received the packet with the 200 response and then send another ACK after receiving the FIN, ACK, and then finally a RST, ACK.So, an example of normal handshake flow would be:
200 response (From IHS)
ACK (From eclient)
FIN, ACK (From IHS)
ACK (From eclient)
RST, ACK (From eclient)
This filter shows a normal handshake: (ip.addr eq 172.20.73.151 and ip.addr eq 10.15.101.131) and (tcp.port eq 1908 and tcp.port eq 80)
Ethereal_screenshot.jpg shows both these transmissions.
IBM HTTP Server then requested assistance from eClient support to determine why a premature RST was being issued from the eClient side.
eClient Ssupport confirmed that these signals are NOT coming from either the eClient viewer applet code or the eClient code, but are being issued by the Java plugin that is used by eClient viewer applet.
This is because DB2 Content Manager code on the eClient side does not have the capability to make the low level calls that issue an RST, ACK etc.
So, the question now becomes, why is the Java plugin issuing the premature RST? DB2 Content Manager Development or Support do not have either the tools or access to the Java source, to determine this.
Finally, we performed tests using different versions of the Java plugin in combination with different versions of the IE browser (IE6, IE7). Here are the results:
- error occurs every time with all versions of Sun Java plugin versions 1.5.0_xx and IE6
- error occurred only once with Sun Java plugin version 1.4.2_16 and IE6
- error occurred only once with IBM Java 2 JRE 1.5.0 J9 VM plugin and IE6
- error NEVER occurred with Sun Java plugin 1.4.2_15 and IE6
- error NEVER occurred with Sun Java plugin 1.4.2_15, Sun Java plugin 1.4.2_16, IBM Java 2 JRE 1.5.0 J9 VM and IE7
- error occurred every time with all versions of Sun Java plugin versions 1.5.0_xx and IE7
Console traces for these combinations have been sent, along with all the other files mentioned in this report, to Dave Korbel.
Windows XP SP2
FULL JDK VERSION(S):
1.5.0_13
1.6.0_03
DESCRIPTION:
We are seeing a problem with the Java Plugin when running IBM's DB2 Content Manager (CM) eClient applet.
The problem we are facing is that intermittently and without any consistency to it, they get an 'Unable to open selected document' error (Screenshot in JavaVersion_1_5_08.JPG).
The error is reproduced by, rapidly opening documents returned as results of a search, one after the other, by clicking on each document icon on the results page (Screenshot in Results.jpg), to view it in the eClient's viewer applet. The viewer applet requires the Java plugin to run.
eClient Support and CM Support thorougly investigated this issue using traces of all the DB2 Content Manager layers that are involved in the retrieval of the document and none of the CM component traces showed any problem with retrieving the document into the browser. Since the documents are being viewed in the eClient viewer applet which uses the Java plugin to run, eClient Support had the customer capture
a Java console trace of using JRE 1.5.0_08 which showed a java.net.SocketTimeoutException:
java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(Unknown Source)
at java.io.BufferedInputStream.fill(Unknown Source)
at java.io.BufferedInputStream.read1(Unknown Source)
at java.io.BufferedInputStream.read(Unknown Source)
at sun.net.www.http.HttpClient.parseHTTPHeader(Unknown Source)
at sun.net.www.http.HttpClient.parseHTTP(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
at com.ibm.idm.applet.IDMViewerApplet.loadDocument(IDMViewerApplet.java:1352)
at com.ibm.idm.applet.IDMViewerApplet.run(IDMViewerApplet.java:635)
at java.lang.Thread.run(Unknown Source)
We are using default settings for the plugin and JRE 1.5.0_08 has infinite readtimeout and connectiontimeout as the default values. Therefore it is very strange that the read time out errors are occuring with the default values of infinite read and connection timeouts.
An Ethereal network packet trace was then captured (Test_Ethereal.cap) while reproducing the error, to further isolate the problem as the next step. The packet trace shows communication between IHS|Websphere side (10.15.101.131) and the eClient side (172.20.73.151).
At this stage, the issue was transferred to IBM HTTP Server Support, who found an error in the handshake between eClient side and the HTTP Server side signals, in the network packet trace. Specifically, they noticed that the eClient side of the connection issued a premature RST as the packet trace in Test_Ethereal.cap clearly shows.
On one connection the eclient sends a POST to IHS and then sends a FIN, ACK indicating it's done sending data to IHS. The web server then responds to eclient with an ACK and then another ACK and then the 200 response. But then the eclient appears to prematurely send a RST, ACK before the web server had sent the FIN, ACK indicating it was done sending data. The Filter to isolate the packets for this erroneous handshake is: (ip.addr eq 172.20.73.151 and ip.addr eq 10.15.101.131) and (tcp.port eq 1910 and tcp.port eq 80)
A normal handshake would require that the eclient machine should have issued an ACK to acknowledge it received the packet with the 200 response and then send another ACK after receiving the FIN, ACK, and then finally a RST, ACK.So, an example of normal handshake flow would be:
200 response (From IHS)
ACK (From eclient)
FIN, ACK (From IHS)
ACK (From eclient)
RST, ACK (From eclient)
This filter shows a normal handshake: (ip.addr eq 172.20.73.151 and ip.addr eq 10.15.101.131) and (tcp.port eq 1908 and tcp.port eq 80)
Ethereal_screenshot.jpg shows both these transmissions.
IBM HTTP Server then requested assistance from eClient support to determine why a premature RST was being issued from the eClient side.
eClient Ssupport confirmed that these signals are NOT coming from either the eClient viewer applet code or the eClient code, but are being issued by the Java plugin that is used by eClient viewer applet.
This is because DB2 Content Manager code on the eClient side does not have the capability to make the low level calls that issue an RST, ACK etc.
So, the question now becomes, why is the Java plugin issuing the premature RST? DB2 Content Manager Development or Support do not have either the tools or access to the Java source, to determine this.
Finally, we performed tests using different versions of the Java plugin in combination with different versions of the IE browser (IE6, IE7). Here are the results:
- error occurs every time with all versions of Sun Java plugin versions 1.5.0_xx and IE6
- error occurred only once with Sun Java plugin version 1.4.2_16 and IE6
- error occurred only once with IBM Java 2 JRE 1.5.0 J9 VM plugin and IE6
- error NEVER occurred with Sun Java plugin 1.4.2_15 and IE6
- error NEVER occurred with Sun Java plugin 1.4.2_15, Sun Java plugin 1.4.2_16, IBM Java 2 JRE 1.5.0 J9 VM and IE7
- error occurred every time with all versions of Sun Java plugin versions 1.5.0_xx and IE7
Console traces for these combinations have been sent, along with all the other files mentioned in this report, to Dave Korbel.