On Tue, 2013-03-12 at 00:25 +0000, Mark Thomas wrote: > I have been tracking down a problem with the Autobahn test suite and > APR/native connector when using SSL (all is fine with non-SSL). > > In the test Autobahn sends a 16MB frame to the server which the server > echos back to the client. > > The problem I am seeing is with a non-blocking write in the > AprServletOutputStream [1]. > > If a write returns EAGAIN (line 97) the socket is added to the poller > for write notifications. The poller immediately returns the socket as > ready for write. Another write is attempted that returns EAGAIN and the > code enters an infinite loop with no more data ever written to the socket. > > If I add a delay around line 46 that slows the rate of writing down, > EAGAIN is never returned and the test completes successfully. > > I assume I am doing something wrong. Pointers appreciated.
So I don't know precisely, but for non blocking, you're not doing the same thing I'm doing (which went through stress tests successfully on some platforms - but not on OS X, the OS is too cool for using it for this kind of dirty work, I presume). Here are some differences (that could be attempted): - to set non blocking, I don't use optSet with APR_SO_NONBLOCK (it did weird things at that time, not 100% sure now), but Socket.timeoutSet(socket, 0) since Mladen told me that is the proper way to set non blocking mode - to do the actual send of the bytes, I use sendibb (which is sendib with an internal byte buffer), I think it's not the same as the regular send since it doesn't retry (says the javadoc, not sure if it can be fully trusted ;) ) - I check if it needs to be put in the poller using the number of bytes wrtten (if 0, it goes to the poller, if not, write again if there's more data), not some status like EAGAIN (IMO that's riskier, since the exact bahavior of statuses are sometimes platform specific) - to exit non blocking mode, I set the previous timeout value and use sendbb (again, with the internal byte buffer) - I don't use syncs on IO, the design of the async in Servlet 3.1 is supposed to allow avoiding that (of course, if the user does concurrent writes without a lock on his own, it will bomb, but IMO, it should) Rémy --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
