On 21/10/2013 15:26, Mark Thomas wrote: > On 19/10/2013 23:31, Mark Thomas wrote: >> On 18/10/2013 19:37, Mark Thomas wrote: >>> On 18/10/2013 13:54, Mark Thomas wrote: >>>> On 18/10/2013 12:48, Mark Thomas wrote: >>>>> When it goes wrong, the sequence is: >>>>> Read result [1] >>>>> Read result [48] >>>>> Read result [-20014] >>>>> 18-Oct-2013 12:23:25.298 SEVERE [http-apr-8443-exec-1] >>>>> websocket.drawboard.DrawboardEndpoint.onError onError: >>>>> java.io.IOException: Unexpected error [20,014] reading data from the >>>>> APR/native socket [364,180,784]. >>>> >>>> I've dug in to what could trigger the 20014 error code. I've got as far >>>> as ssl_socket_recv() in native\src\sslnetwork.c >>>> >>>> There appear to be a number of ways that the code could end up returning >>>> 20014. The next step is to figure out which it is. >>> >>> I've made some progress. I've captured a failure with Wireshark with an >>> SSL configuration that Wireshark can decrypt with the server's private >>> key (SSLProtocol="SSLv3", SSLCipherSuite="RC4-MD5") and it shows nothing >>> unusual until Tomcat initiates the close. >>> >>> To progress I need to create a new tcnative with some debug info so I >>> guess I'll have to return to trying to get my local build environment >>> set up correctly. >> >> No joy getting a Windows build environment created but the error also >> occurs on Linux and I do have a working build environment there. The >> various errors reported in ssl_socket_recv() are: >> >> SSL_READ returns -1 >> SSL_get_error returns 5 (SSL_ERROR_SYSCALL) >> apr_get_netos_error returns 11 (APR_STATUS_IS_ENOTSOCK) >> >> At this point it looks like the issue is in the tcnative / APR / OpenSSL >> integration and I am way out of my depth. >> >> Looking at the source code for APR reads, the InternalAprInputBuffer >> uses Socket.recvbb() whereas AprServletInputStream current uses >> Socket.recv(). My short-term plan is to switch AprServletInputStream to >> Socket.recvbb() for SSL and see if that fixes the problem. > > It doesn't. I have removed the code that swallowed this error and the > easiest way to reproduce it is to open the drawing board app and hold > down F5 to refresh the page. > > I'm going to spend a little more time looking at the Tomcat side of this > but I'm fairly sure it is going to need someone more familiar with C to > provide some pointers.
Having tested various theories as to why this was happened I tried tested the theory "is isn't an error, carry on" and that appears to have worked. Treating the error in the same manner as EAGAIN does not drop the client connection and that connection continues to work. I have added some debug logging we can enable if we suspect this is causing problems in the future. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
