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: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
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to