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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
