On 12/03/2013 09:47, Remy Maucherat wrote: > On Tue, 2013-03-12 at 00:25 +0000, Mark Thomas wrote:
<snip/> >> 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) Thanks for the pointers. I tried a few of them (the less invasive ones) with no luck. I'm putting together a test case that demonstrates the problem. That should make it very simple to determine if the root cause lies in APR or my code. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
