Ok, I have a resolution to this, it's a IPv6 problem. The reason it worked on my virtual machine, is cause the virtual machine doesn't have IPv6
When I add <jvmarg value="-Djava.net.preferIPv4Stack=true"/> To the unit tests, it works fine on Windows. Here is what led me to believe in this: http://blog.bielu.com/2011/11/hotspot-64bit-server-hangs-on-socket.html > -----Original Message----- > From: Filip Hanik (mailing lists) [mailto:devli...@hanik.com] > Sent: Wednesday, July 11, 2012 2:54 PM > To: 'Tomcat Developers List' > Subject: RE: Unit tests and trunk > > The idea of creating a VM that is like mine was a good one. > I did a clean install of Windows 7 64 bit, and it works like a charm. > My network stack must have something installed at the network stack > > Filip > > > -----Original Message----- > > From: Mark Thomas [mailto:ma...@apache.org] > > Sent: Wednesday, July 11, 2012 1:32 PM > > To: Tomcat Developers List > > Subject: Re: Unit tests and trunk > > > > On 11/07/2012 20:13, Filip Hanik (mailing lists) wrote: > > > > > > > > >> -----Original Message----- > > >> From: Filip Hanik (mailing lists) [mailto:devli...@hanik.com] > > >> Sent: Wednesday, July 11, 2012 10:13 AM > > >> To: 'Tomcat Developers List' > > >> Subject: RE: Unit tests and trunk > > >> > > >> > > >> > > >>> -----Original Message----- > > >>> From: Mark Thomas [mailto:ma...@apache.org] > > >>> Sent: Wednesday, July 11, 2012 2:45 AM > > >>> To: Tomcat Developers List > > >>> Subject: Re: Unit tests and trunk > > >>> > > >>> 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? > > >> [Filip Hanik] > > >> Correct, as it should. The buffer should fill up very quick, and > when > > >> the > > >> buffer is full NIO returns 0, can't write. > > >> So there are two problems: > > >> a) The selector doesn't work the same in Java 7 as it does in Java > 5 > > and > > >> 6 > > >> b) Starting a new selector turns non blocking writes into blocking, > > even > > >> when I write 10MB in the TestOutputBuffer test, there is not a > single > > >> socket.write that returns 0. Removing the Selector.open call, and > > >> immediately we have a hit return 0 as expected. > > >> > > >> > > >>> > > >>> 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? > > >> [Filip Hanik] > > >> Can't think of anything but a bug in the JDK. I'll keep > > investigating. > > >> Possibly we have to move the async NIO stuff to get it to work > > > [Filip Hanik] > > > Btw, this affects the BIO connector too. The write blocks and hangs > > forever. > > > Maybe it's just my Windows 7 system. Works fine on linux. > > > > Let me see if I can find (or create if necessary) a clean-ish Windows > 7 > > VM to test this on. > > > > 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
