2014-03-12 15:44 GMT+01:00 Bill Barker <billbar...@apache.org>: > Full details are available at: > > http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-test-nio2/index.html >
So, after debugging it, I can confirm there's an issue with the test TestWebSocketFrameClient.testConnectToServerEndpointSSL It does seem to be caused by a characteristic of NIO2, where the data has to be encrypted inline (unlike the NIO1 connector). I don't see any reasonable workaround for this. The test uses a lot of resources (2GB+ of RAM for me, plus significant CPU), so this processing time could spike. This then seems to cause a deadlock in the websockets code, which I have been able to reproduce 100% of the time by adding a Thread.sleep(20) at the beginning of Nio(2)ServletOutputStream.doWrite (for both NIO and NIO2 connectors, the behavior then becomes identical). So this can apparently could only affect heavily loaded servers using SSL. The deadlock is later broken up by the FutureSendHandler timeout. Although this failure only occurs with the NIO2 connector, I don't consider its behavior to be incorrect, as non blocking is not supposed to block on any IO operation, but this doesn't mean all calls need to have zero processing time. I'll try to investigate more this likely deadlock sometime later if Mark doesn't have any ideas about it. Rémy
