> -----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
>
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
