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:[email protected]]
>> 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:[email protected]]
>>> 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:[email protected]]
>>>> 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:[email protected]]
>>>>> 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: [email protected]
>>>>> For additional commands, e-mail: [email protected]
>>>>
>>>>
>>>>
>>>> --------------------------------------------------------------------
>> -
>>>> To unsubscribe, e-mail: [email protected]
>>>> For additional commands, e-mail: [email protected]
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
