[jboss-remoting-issues] [JBoss JIRA] (JBREM-1307) TimedOutputStream OutputTimerTask call to close on SSL OutputStream blocks

Ron Sigal (JIRA) jira-events at lists.jboss.org
Mon Nov 4 18:12:02 EST 2013


     [ https://issues.jboss.org/browse/JBREM-1307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ron Sigal updated JBREM-1307:
-----------------------------

    Attachment: jboss-remoting.jar
                jboss-remoting-src.jar


This fix will be in release 2.5.4.SP5.  I'm attaching a jboss-remoting.jar in case someone wants to try it.
                
> 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
>         Attachments: jboss-remoting-src.jar, jboss-remoting.jar
>
>
> 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
For more information on JIRA, see: http://www.atlassian.com/software/jira


More information about the jboss-remoting-issues mailing list