On 13/03/2013 14:07, Mladen Turk wrote: > On 03/13/2013 02:47 PM, Mark Thomas wrote: >> On 13/03/2013 13:36, Mark Thomas wrote: >>> On 13/03/2013 13:12, Mladen Turk wrote: >> >>>> I can create a debug version which would write couple of lines to >>>> the dbgview.exe window (from SysInternals >>>> http://technet.microsoft.com/en-us/sysinternals/bb896647) >>>> >>>> Fancy to give it a shot. >>>> It would be cool to see what are the actual internal results of >>>> SSL_write API call >>> >>> Thanks. Setting up to test with that now. >> >> http://people.apache.org/~markt/random/2013-03-13-apr-sos-ssl-debug.log >> >> Hope this helps find a fix. >> > > 00000024 7.85507011 [3976] SSL_write returned -1, > apr_get_netos_error=730035 SSL_get_error=3 > > Ok, that's a first failure with is WSAEWOULDBLOCK and SSL_get_error=3 is > SSL_ERROR_WANT_WRITE > > 00000026 7.85627747 [3976] SSL_write returned -1, > apr_get_netos_error=0 SSL_get_error=1 > > That's a problem > apr_get_netos_error returned zero (and thats what we return) > However SSL_get_error returned SSL_ERROR_SSL (1) and we don't handle that! > > Sending you a version that returns APR_EGENERAL on SLL_ERROR_SSL ...
Thanks. That fails fast which is good but still fails. Fundamentally we need to be able to handle the situation when we have some, but not enough data for OpenSSL. On a possibly related topic... I've noticed that the non-blocking writes via APR/native doesn't behave as I would expect. Consider the output from the test case [1] The writes at line 3 and 8 suggest (to me at least) that the server hasn't yet written any data as the return value from the Socket.send call is zero. However, clearly data has been written since line 5 tells us that the client has read some data. I am certain this isn't a timing issue with the log messages because I have stepped through this with a debugger. Why doesn't APR/native return the bytes written for Socket.send? Mark [1] http://people.apache.org/~markt/random/2013-03-13-TestSocket-output.txt --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
