[
https://issues.jboss.org/browse/JBREM-1307?page=com.atlassian.jira.plugin...
]
Saravanan Bellan commented on JBREM-1307:
-----------------------------------------
Happen to come across this bug since we had the same stack trace. On Windows/Java 6, we
were able to overcome this socket.close() hang by setting setSoTimeout(true,
<seconds>) as specified at
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6447412
TimedOutputStream OutputTimerTask call to close on SSL OutputStream
blocks
--------------------------------------------------------------------------
Key: JBREM-1307
URL:
https://issues.jboss.org/browse/JBREM-1307
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: transport
Affects Versions: 2.2.3.SP2
Environment: JBoss EAP 4.3.0 CP08 and CP10
Reporter: Doug Grove
Assignee: Ron Sigal
Labels: messaging
In order to provide a mechanism for timing out a network/socket write operation, the
org.jboss.remoting.transport.socket.TimedOutputStream class starts a timer. If the
duration of the write operation exceeds the timer interval, then the timer will call
close() on the output stream. This interrupts the output stream write() operation and
causes the write operation to throw an IOException.
When the output stream uses secure sockets (SSL), however, the call to close() on the
output stream can block indefinitely. The threads associated with the write() and close()
operation will only clear when the tcp keepalive timeout mechanism in the operation system
is invoked.
This appears to be related to a know bug in the java runtime:
http://bugs.sun.com/view_bug.do?bug_id=6358629
Specifically, in a thread dump you will see:
"Timer-9" daemon prio=10 tid=0x5016c400 nid=0x2638 waiting on condition
[0x4cbad000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x585021a0> (a
java.util.concurrent.locks.ReentrantLock$NonfairSync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)
at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186)
at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:720)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.sendAlert(SSLSocketImpl.java:1720)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.warning(SSLSocketImpl.java:1564)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.closeInternal(SSLSocketImpl.java:1362)
- locked <0x58502030> (a com.sun.net.ssl.internal.ssl.SSLSocketImpl)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.close(SSLSocketImpl.java:1301)
at com.sun.net.ssl.internal.ssl.AppOutputStream.close(AppOutputStream.java:80)
at
org.jboss.remoting.transport.socket.TimedOutputStream.close(TimedOutputStream.java:57)
at
org.jboss.remoting.transport.socket.TimedOutputStream$OutputTimerTask.run(TimedOutputStream.java:145)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see:
http://www.atlassian.com/software/jira