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]

Reply via email to