On 11/07/2012 02:27, Filip Hanik (mailing lists) wrote: > Here's what I've found out so far > > The patch below does solve the problem. In a rather remarkable way. > The line > int cnt = socket.write(buf); //write the data > > never returns 0, meaning the writes are always blocking. Even though they > are not supposed to be. > Remove this patch, and socket.write(buf) returns 0, and then we never get > issued the OP_WRITE from the selector itself.
I'm not sure I follow the above. Remove the patch and it returns 0? Regardless, it seems very strange that the patch below fixes it. I had a quick look through the Java source and couldn't see anything immediately obvious. Any ideas what is going on? Mark > > Index: java/org/apache/tomcat/util/net/NioBlockingSelector.java > =================================================================== > --- java/org/apache/tomcat/util/net/NioBlockingSelector.java (revision > 1359329) > +++ java/org/apache/tomcat/util/net/NioBlockingSelector.java (working > copy) > @@ -89,6 +89,12 @@ > int keycount = 1; //assume we can write > long time = System.currentTimeMillis(); //start the timeout timer > try { > + > + synchronized (Selector.class) { > + Selector s = Selector.open(); > + s.close(); > + } > + > while ( (!timedout) && buf.hasRemaining()) { > if (keycount > 0) { //only write if we were registered for > a write > int cnt = socket.write(buf); //write the data > >> -----Original Message----- >> From: Filip Hanik (mailing lists) [mailto:devli...@hanik.com] >> Sent: Tuesday, July 10, 2012 10:43 AM >> To: 'Tomcat Developers List' >> Subject: RE: Unit tests and trunk >> >> Ok, definitely a bug in Java 7/Windows 7. >> If I turn on ProcMon from sysinternals to try to figure out what is >> going >> on, the test succeeds everytime. Shutdown procmon, and it hangs again. >> The >> Selector is not registering the OP_WRITE event >> >> Filip >> >> >>> -----Original Message----- >>> From: Filip Hanik (mailing lists) [mailto:devli...@hanik.com] >>> Sent: Monday, July 09, 2012 2:31 PM >>> To: 'Tomcat Developers List' >>> Subject: RE: Unit tests and trunk >>> >>> This failure happens when the write blocks, and we enter the Selector >>> for a >>> write operation. >>> >>> filip >>> >>>> -----Original Message----- >>>> From: Filip Hanik (mailing lists) [mailto:devli...@hanik.com] >>>> Sent: Monday, July 09, 2012 2:23 PM >>>> To: 'Tomcat Developers List' >>>> Subject: RE: Unit tests and trunk >>>> >>>> I'm on Windows 7 and see TestOutputBuffer fail inconsistently with >>> Java >>>> 7 >>>> Most runs are failures. >>>> >>>> I'll be looking into this this week >>>> >>>>> -----Original Message----- >>>>> From: Mark Thomas [mailto:ma...@apache.org] >>>>> Sent: Monday, July 09, 2012 4:33 AM >>>>> To: Tomcat Developers List >>>>> Subject: Unit tests and trunk >>>>> >>>>> With the fixes over the weekend for setting traffic class, I now >> see >>>> the >>>>> unit tests passing consistently for: >>>>> >>>>> Windows: BIO, NIO, APR >>>>> Linux: BIO, NIO >>>>> >>>>> I do see a consistent failure for Linux and APR with the Comet >>> tests. >>>> It >>>>> is the connector stop test failing (the one that was failing in >>>> buildbot >>>>> previously with NIO). I'll take a look at this today. >>>>> >>>>> Mark >>>>> >>>>> ------------------------------------------------------------------ >> -- >>> - >>>>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >>>>> For additional commands, e-mail: dev-h...@tomcat.apache.org >>>> >>>> >>>> >>>> -------------------------------------------------------------------- >> - >>>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >>>> For additional commands, e-mail: dev-h...@tomcat.apache.org >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: dev-h...@tomcat.apache.org >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org