You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Mark Thomas <ma...@apache.org> on 2012/07/09 12:32:33 UTC
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
RE: Unit tests and trunk
Posted by "Filip Hanik (mailing lists)" <de...@hanik.com>.
Oracle reopened
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7115226
based on the bug we filed
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7183450
Filip
> -----Original Message-----
> From: Mark Thomas [mailto:markt@apache.org]
> Sent: Thursday, July 12, 2012 1:30 AM
> To: Tomcat Developers List
> Subject: Re: Unit tests and trunk
>
> On 12/07/2012 02:05, Filip Hanik wrote:
> > I can reproduce the bug in both our unit tests and the original bug
> report. further more I can turn non blocking into blocking by opening an
> closing a selector that is never used.
> >
> > definitely a bug, since a jvm/network flag resolves it.
> >
> > while your vm may support ipv6, there is still an additional software
> layer.
>
> Indeed and all are present. The reason I said it claims to support IPv6
> is that I hadn't tested it to confirm what the OS was claiming was
> indeed true.
>
> > I'm sure there will be more bug reports as more people turn to java 7
> on windows/hardware
>
> Yep.
>
> Mark
>
> >
> > Sent from my iPhone
> >
> > On Jul 11, 2012, at 16:42, Mark Thomas <ma...@apache.org> wrote:
> >
> >> On 11/07/2012 23:30, Filip Hanik (mailing lists) wrote:
> >>> I wasn't able to reproduce on a Win 7 VM because the VM environment
> itself
> >>> doesn't support IPv6
> >>
> >> Given who we work for, the opportunities for humorous comments is
> >> extensive :)
> >>
> >> I'll settle for saying that I've double checked the VM I have and it
> >> does (claim to) support IPv6. I'll try out the test case provided in
> the
> >> original bug report.
> >>
> >> Mark
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: dev-help@tomcat.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Unit tests and trunk
Posted by Mark Thomas <ma...@apache.org>.
On 12/07/2012 02:05, Filip Hanik wrote:
> I can reproduce the bug in both our unit tests and the original bug report. further more I can turn non blocking into blocking by opening an closing a selector that is never used.
>
> definitely a bug, since a jvm/network flag resolves it.
>
> while your vm may support ipv6, there is still an additional software layer.
Indeed and all are present. The reason I said it claims to support IPv6
is that I hadn't tested it to confirm what the OS was claiming was
indeed true.
> I'm sure there will be more bug reports as more people turn to java 7 on windows/hardware
Yep.
Mark
>
> Sent from my iPhone
>
> On Jul 11, 2012, at 16:42, Mark Thomas <ma...@apache.org> wrote:
>
>> On 11/07/2012 23:30, Filip Hanik (mailing lists) wrote:
>>> I wasn't able to reproduce on a Win 7 VM because the VM environment itself
>>> doesn't support IPv6
>>
>> Given who we work for, the opportunities for humorous comments is
>> extensive :)
>>
>> I'll settle for saying that I've double checked the VM I have and it
>> does (claim to) support IPv6. I'll try out the test case provided in the
>> original bug report.
>>
>> Mark
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Unit tests and trunk
Posted by Filip Hanik <de...@hanik.com>.
I can reproduce the bug in both our unit tests and the original bug report. further more I can turn non blocking into blocking by opening an closing a selector that is never used.
definitely a bug, since a jvm/network flag resolves it.
while your vm may support ipv6, there is still an additional software layer.
I'm sure there will be more bug reports as more people turn to java 7 on windows/hardware
Sent from my iPhone
On Jul 11, 2012, at 16:42, Mark Thomas <ma...@apache.org> wrote:
> On 11/07/2012 23:30, Filip Hanik (mailing lists) wrote:
>> I wasn't able to reproduce on a Win 7 VM because the VM environment itself
>> doesn't support IPv6
>
> Given who we work for, the opportunities for humorous comments is
> extensive :)
>
> I'll settle for saying that I've double checked the VM I have and it
> does (claim to) support IPv6. I'll try out the test case provided in the
> original bug report.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Unit tests and trunk
Posted by Mark Thomas <ma...@apache.org>.
On 11/07/2012 23:30, Filip Hanik (mailing lists) wrote:
> I wasn't able to reproduce on a Win 7 VM because the VM environment itself
> doesn't support IPv6
Given who we work for, the opportunities for humorous comments is
extensive :)
I'll settle for saying that I've double checked the VM I have and it
does (claim to) support IPv6. I'll try out the test case provided in the
original bug report.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
RE: Unit tests and trunk
Posted by "Filip Hanik (mailing lists)" <de...@hanik.com>.
I opened a new issue pointing back to the old issue
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7183450.
It may take a day or two before your bug shows up in this external database.
> -----Original Message-----
> From: Filip Hanik (mailing lists) [mailto:devlists@hanik.com]
> Sent: Wednesday, July 11, 2012 4:30 PM
> To: 'Tomcat Developers List'
> Subject: RE: Unit tests and trunk
>
>
>
> > -----Original Message-----
> > From: Mark Thomas [mailto:markt@apache.org]
> > Sent: Wednesday, July 11, 2012 4:28 PM
> > To: Tomcat Developers List
> > Subject: Re: Unit tests and trunk
> >
> > On 11/07/2012 22:39, Filip Hanik (mailing lists) wrote:
> > > 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
> >
> > Hmm. It looks like Oracle failed to reproduce the issue - possibly
> > because the IPv6 part was not clear in the original bug report.
> Probably
> > time to raise an issue with Oracle with clearer instructions to
> > reproduce. (I have a clean Win 7 VM I am happy to trial any test case
> on
> > if that helps).
> [Filip Hanik]
> I wasn't able to reproduce on a Win 7 VM because the VM environment
> itself
> doesn't support IPv6
>
>
>
> >
> > Mark
> >
> >
> > >
> > >> -----Original Message-----
> > >> From: Filip Hanik (mailing lists) [mailto:devlists@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:markt@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:devlists@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:markt@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-unsubscribe@tomcat.apache.org
> > >>> For additional commands, e-mail: dev-help@tomcat.apache.org
> > >>
> > >>
> > >>
> > >> -------------------------------------------------------------------
> --
> > >> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > >> For additional commands, e-mail: dev-help@tomcat.apache.org
> > >
> > >
> > >
> > > --------------------------------------------------------------------
> -
> > > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > > For additional commands, e-mail: dev-help@tomcat.apache.org
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
RE: Unit tests and trunk
Posted by "Filip Hanik (mailing lists)" <de...@hanik.com>.
> -----Original Message-----
> From: Mark Thomas [mailto:markt@apache.org]
> Sent: Wednesday, July 11, 2012 4:28 PM
> To: Tomcat Developers List
> Subject: Re: Unit tests and trunk
>
> On 11/07/2012 22:39, Filip Hanik (mailing lists) wrote:
> > 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
>
> Hmm. It looks like Oracle failed to reproduce the issue - possibly
> because the IPv6 part was not clear in the original bug report. Probably
> time to raise an issue with Oracle with clearer instructions to
> reproduce. (I have a clean Win 7 VM I am happy to trial any test case on
> if that helps).
[Filip Hanik]
I wasn't able to reproduce on a Win 7 VM because the VM environment itself
doesn't support IPv6
>
> Mark
>
>
> >
> >> -----Original Message-----
> >> From: Filip Hanik (mailing lists) [mailto:devlists@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:markt@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:devlists@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:markt@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-unsubscribe@tomcat.apache.org
> >>> For additional commands, e-mail: dev-help@tomcat.apache.org
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: dev-help@tomcat.apache.org
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Unit tests and trunk
Posted by Mark Thomas <ma...@apache.org>.
On 11/07/2012 22:39, Filip Hanik (mailing lists) wrote:
> 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
Hmm. It looks like Oracle failed to reproduce the issue - possibly
because the IPv6 part was not clear in the original bug report. Probably
time to raise an issue with Oracle with clearer instructions to
reproduce. (I have a clean Win 7 VM I am happy to trial any test case on
if that helps).
Mark
>
>> -----Original Message-----
>> From: Filip Hanik (mailing lists) [mailto:devlists@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:markt@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:devlists@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:markt@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-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
RE: Unit tests and trunk
Posted by "Filip Hanik (mailing lists)" <de...@hanik.com>.
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:devlists@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:markt@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:devlists@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:markt@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-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
RE: Unit tests and trunk
Posted by "Filip Hanik (mailing lists)" <de...@hanik.com>.
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:markt@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:devlists@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:markt@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Unit tests and trunk
Posted by Mark Thomas <ma...@apache.org>.
On 11/07/2012 20:13, Filip Hanik (mailing lists) wrote:
>
>
>> -----Original Message-----
>> From: Filip Hanik (mailing lists) [mailto:devlists@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:markt@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
RE: Unit tests and trunk
Posted by "Filip Hanik (mailing lists)" <de...@hanik.com>.
> -----Original Message-----
> From: Filip Hanik (mailing lists) [mailto:devlists@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:markt@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.
>
> >
> > 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:devlists@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:devlists@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:devlists@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:markt@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-unsubscribe@tomcat.apache.org
> > >>>>> For additional commands, e-mail: dev-help@tomcat.apache.org
> > >>>>
> > >>>>
> > >>>>
> > >>>> -----------------------------------------------------------------
> --
> > -
> > >> -
> > >>>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > >>>> For additional commands, e-mail: dev-help@tomcat.apache.org
> > >>>
> > >>>
> > >>>
> > >>> ------------------------------------------------------------------
> --
> > -
> > >>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > >>> For additional commands, e-mail: dev-help@tomcat.apache.org
> > >>
> > >>
> > >>
> > >> -------------------------------------------------------------------
> --
> > >> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > >> For additional commands, e-mail: dev-help@tomcat.apache.org
> > >
> > >
> > >
> > > --------------------------------------------------------------------
> -
> > > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > > For additional commands, e-mail: dev-help@tomcat.apache.org
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
RE: Unit tests and trunk
Posted by "Filip Hanik (mailing lists)" <de...@hanik.com>.
> -----Original Message-----
> From: Mark Thomas [mailto:markt@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:devlists@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:devlists@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:devlists@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:markt@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-unsubscribe@tomcat.apache.org
> >>>>> For additional commands, e-mail: dev-help@tomcat.apache.org
> >>>>
> >>>>
> >>>>
> >>>> -------------------------------------------------------------------
> -
> >> -
> >>>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> >>>> For additional commands, e-mail: dev-help@tomcat.apache.org
> >>>
> >>>
> >>>
> >>> --------------------------------------------------------------------
> -
> >>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> >>> For additional commands, e-mail: dev-help@tomcat.apache.org
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: dev-help@tomcat.apache.org
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Unit tests and trunk
Posted by Mark Thomas <ma...@apache.org>.
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:devlists@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:devlists@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:devlists@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:markt@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-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>>>
>>>>
>>>>
>>>> --------------------------------------------------------------------
>> -
>>>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
RE: Unit tests and trunk
Posted by "Filip Hanik (mailing lists)" <de...@hanik.com>.
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.
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:devlists@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:devlists@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:devlists@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:markt@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-unsubscribe@tomcat.apache.org
> > > > For additional commands, e-mail: dev-help@tomcat.apache.org
> > >
> > >
> > >
> > > --------------------------------------------------------------------
> -
> > > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > > For additional commands, e-mail: dev-help@tomcat.apache.org
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
RE: Unit tests and trunk
Posted by "Filip Hanik (mailing lists)" <de...@hanik.com>.
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:devlists@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:devlists@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:markt@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-unsubscribe@tomcat.apache.org
> > > For additional commands, e-mail: dev-help@tomcat.apache.org
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
RE: Unit tests and trunk
Posted by "Filip Hanik (mailing lists)" <de...@hanik.com>.
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:devlists@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:markt@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-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
RE: Unit tests and trunk
Posted by "Filip Hanik (mailing lists)" <de...@hanik.com>.
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:markt@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org