tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sebastiaan van Erk <sebs...@sebster.com>
Subject Re: NIOSelector busy wait
Date Fri, 08 Jun 2007 08:53:59 GMT
Hi,

I found out why I was so consistently able to reproduce the NIO busy 
wait bug: I was closing the http socket on the client side with a 
SO_LINGER value of 0, causing a RST packet to be received by Tomcat 
while the SelectionKey was still registered with interestOps of 0.

Commenting out the setSoLinger() makes the problem much harder to 
reproduce. Since I also know the exact cause of the problem now, I will 
make a small test case program to exhibit the problem in the very near 
future.

The problem with many modern NAT routers is that they drop "idle" 
connections very quickly (I've seen 30 seconds to 1 minute), which 
causes a RST packet to be received by Tomcat as soon as the comet 
servlet tries to write some data to the (timed out client). So this is 
still a serious issue for me.

As a workaround I'm guessing the best solution is to use the native APR 
connector until at least until a stable JDK is released which fixes the 
bug; APR uses native selection, does it not?

Regards,
Sebastiaan



Sebastiaan van Erk wrote:
> Filip Hanik - Dev Lists wrote:
>> Sebastiaan van Erk wrote:
>>> Hi,
>>>
>>> Filip Hanik - Dev Lists wrote:
>>>> it will return 0 after the timeout has expired if there was no events.
>>>> most likely its not a bug in the JDK but in your linux kernel/distro
>>>>
>>> I just found the Sun bug report + workaround confirming this issue 
>>> as a Linux JDK bug.
>> The work around is useless, its for a selector with only one key, in 
>> Tomcat the poller can handle thousands of keys, trying to cancel them 
>> all is not really an option.
>> if you're able to create a "reproducable scenario" we can try to come 
>> up with a different work around
>> it is supposed to appear in JDK 6, u3 as well.
>> Filip
>>
> Yes, it's all a bit of a bummer really. I'm really having trouble with 
> this bug (also in my own NIO code on the client side), and I don't 
> understand why. It's very reproducable for me in my application but I 
> have not been able to isolate it yet in a small test case. The 
> "CometEchoTest" (which I mailed about a bit earlier) was my first 
> attempt to isolate the problem; but so far, no luck. I will definately 
> be looking into this later, however I'm running into a deadline, so I 
> won't be able to spend more time on it this week.
>
> I saw the JDK 6, u3 bit, which I find kind of dissappointing as well. 
> I'm writing code for parties which are going to have to upgrade from 
> 1.4 to 5 already due to Comet, and waiting for u3 of JDK 6 is not 
> going to be an option for me.
>
> If I find more useful information I'll definately let you know; and 
> I'll definately try to make an isolated test case in a bit.
>
> Regards,
> Sebastiaan
>>>
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6403933
>>>
>>> It's fixed in Java 7, earlier versions are not reported to be fixed, 
>>> so I'm guessing they're not backporting the fix, though I hope they 
>>> do, since it's a serious problem.
>>>
>>>> so far I haven't seen the behavior you've explained.
>>>>
>>> In my Comet application I'm seeing this problem consistently: the 
>>> Tomcat poller thread goes into a busy loop with the selector 
>>> returning 0. Could be I'm forgetting to do something which causes 
>>> this, but I haven't found a way to solve the problem yet.
>>>
>>> Regards,
>>> Sebastiaan
>>>
>>>> Filip
>>>>
>>>> Sebastiaan van Erk wrote:
>>>>> Hi,
>>>>>
>>>>> I have a problem that sometimes the NIO selector goes into a busy 
>>>>> wait loop.
>>>>>
>>>>> In line 1430 the code of NIOEndpoint.java,
>>>>>
>>>>>                            keyCount = 
>>>>> selector.select(selectorTimeout);
>>>>>
>>>>> select keeps returning 0 without waiting.
>>>>>
>>>>> I'm running on the latest trunk version of tomcat 6, on Ubuntu 
>>>>> Linux Feisty, with java version:
>>>>>
>>>>> java version "1.6.0"
>>>>> Java(TM) SE Runtime Environment (build 1.6.0-b105)
>>>>> Java HotSpot(TM) Server VM (build 1.6.0-b105, mixed mode)
>>>>>
>>>>> However, I've seen this same behavior with other JDK's (1.5).
>>>>>
>>>>> To me it seems that it's a bug in the JVM implementation because 
>>>>> select should only return 0 if it's woken up, which does not 
>>>>> happen (since all other threads are suspended in my debugger). 
>>>>> However, I was wondering if anybody else has seen this behavior 
>>>>> and perhaps knows what's causing it in the first place.
>>>>>
>>>>> Regards,
>>>>> Sebastiaan
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To start a new topic, e-mail: users@tomcat.apache.org
>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To start a new topic, e-mail: users@tomcat.apache.org
>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To start a new topic, e-mail: users@tomcat.apache.org
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To start a new topic, e-mail: users@tomcat.apache.org
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message