Synopsis : Issue w/ socket.close() for ssl sockets when poweroff on other system.


FULL PRODUCT VERSION :

java version "1.4.2_09"

Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_09-b05)

Java HotSpot(TM) Client VM (build 1.4.2_09-b05, mixed mode)

FULL OPERATING SYSTEM VERSION :

2.4.21-32.0.1.ELsmp #1 SMP Tue May 17 17:52:23 EDT 2005 i686 i686 i386 GNU/Linux

Red Hat Enterprise Linux AS release 3 (Taroon Update 5)

glibc-common-2.3.2-95.33

glib2-2.2.3-2.0

glibc-headers-2.3.2-95.33

glibc-2.3.2-95.33

glib-1.2.10-11.1

glibc-kernheaders-2.4-8.34.1

glibc-devel-2.3.2-95.33


DESCRIPTION OF THE PROBLEM:

    Socket.close() on an SSL socket on Linux hangs if a computer is abruptly removed from the network because of power failure or shutdown ?f. The socket.close() method hangs for 30 minutes or more then returns correctly. If the computer is powered on, then the method completes as soon as the MAC address is rediscovered. The method works in the same scenario on Solaris.

Modifying the TCP parameters have no result (soTimeout / SoLinger), and shutdownInput and shutdownOutput (which may be a work around for normal TCP sockets) are not implemented on SSL sockets.

I?ve tested this with 1.4 (up to Rel 11) and 1.5 (up to Rel 6).

Also tried loading the software on the 1.6 beta ? however there are issues loading the JSSE methods.

I see from the bug report 4726957 that a similar problem may be fixed in mustang (1.6) ?

Please advise on what data is required.

We need whatever fix for release in jdk 1.4.2.


> Tested Bug ID # 4726957 and it does now pass with 1.5.0_07.
Finished the port and tested the software with 1.5.0_07, however it does not fix the problem.
Here is the thread dump of the thread that appears to be locking up.
I've cut out our code, but we are calling the close.
>
> "DefaultTaskRunnerGroup Priority 10 TaskRunner 2" prio=1 tid=0x87c26150 nid=0x7b0c waiting for monitor entry [0x863cf000..0x863cf6f0]
>
> at com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:662)
>
> - waiting to lock <0x8ed1d688> (a java.lang.Object)
>
> at com.sun.net.ssl.internal.ssl.SSLSocketImpl.sendAlert(SSLSocketImpl.java:1622)
>
> at com.sun.net.ssl.internal.ssl.SSLSocketImpl.warning(SSLSocketImpl.java:1475)
>
> at com.sun.net.ssl.internal.ssl.SSLSocketImpl.closeInternal(SSLSocketImpl.java:1315)
>
> - locked <0x8eb15b68> (a com.sun.net.ssl.internal.ssl.SSLSocketImpl)
>
> - locked <0x8ed1d698> (a java.lang.Object)
>
> at com.sun.net.ssl.internal.ssl.SSLSocketImpl.close(SSLSocketImpl.java:1219)
>

==================
Available Dumps :
==================

On machine titan.sfbay.sun.com at location /home/sd158479/Nortel/830777
File Name :

-rwxrwxrwx 1 sd158479 staff 82128021 Jun 22 16:17 nt42sun.zip
-rwxrwxrwx 1 sd158479 staff 82128021 Jun 22 16:16 nt4sun.zip
-rwxrwxrwx 1 sd158479 staff 10 Jun 22 16:18 nt4sun2.zip


> The file contains :
>
> Jcore (java core file)
    and td.txt (java thread dump)
>
>
>
From the Thread Dump it would appear that the problem is
with com.sun.net.ssl.internal.ssl.SSLSocketImpl.close() instead of socket.close().
>
> Also again:
>
> This only happens on Linux ? It works perfect on Solaris.
> And
> The case it fails is if you "pull the plug" the server. Then try and close() the connection on the client.
>
> If you gracefully shutdown the server (init 0 for instance) everything works fine.

>
> In the thread dump look for:
>
> "DefaultTaskRunnerGroup Priority 10 TaskRunner 2" prio=1 tid=0x87c26150 nid=0x7b0c waiting for monitor entry [0x863cf000..0x863cf6f0]
>
> at com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:662)
>
> - waiting to lock <0x8ed1d688> (a java.lang.Object)
>
> at com.sun.net.ssl.internal.ssl.SSLSocketImpl.sendAlert(SSLSocketImpl.java:1622)
>
> at com.sun.net.ssl.internal.ssl.SSLSocketImpl.warning(SSLSocketImpl.java:1475)
>
> at com.sun.net.ssl.internal.ssl.SSLSocketImpl.closeInternal(SSLSocketImpl.java:1315)
>
> - locked <0x8eb15b68> (a com.sun.net.ssl.internal.ssl.SSLSocketImpl)
>
> - locked <0x8ed1d698> (a java.lang.Object)
>
> at com.sun.net.ssl.internal.ssl.SSLSocketImpl.close(SSLSocketImpl.java:1219)

 Which is the thread that is locked waiting on the close()