JDK-6429790 : (se) Selector.select() does not block and returns 0, forever
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.nio
  • Affected Version: 5.0
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2006-05-24
  • Updated: 2011-02-16
  • Resolved: 2006-12-11
Related Reports
Duplicate :  
JDK-4919127 - (so spec) Confusing relationship between OP_CONNECT and OP_WRITE
Description
FULL PRODUCT VERSION :
java -version
java version "1.5.0_06"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode)


ADDITIONAL OS VERSION INFORMATION :
Windows XP SP2 (Pentium 4, hyperthreading)

A DESCRIPTION OF THE PROBLEM :
The documentation for Selector describes precisely when a call to select() will return, i.e. "at least one channel is selected, this selector's wakeup method is invoked, or the current thread is interrupted, whichever comes first."
I found two scenario where select() returns 0 without blocking, forever:
- When a channel registers with the Selector with an interest set of 0.
- When a socket channel that had not completed the connection process (invoking finishConnect until returning true) is registered with READ/WRITE interest set without CONNECT.

This behaviour is not consistent with the doc, maybe it can be considered a bug, or maybe the doc should change.


REPRODUCIBILITY :
This bug can be reproduced always.
Comments
EVALUATION -- The relationship between OP_CONNECT and OP_WRITE is covered by 4919127 so I will close this bug.
11-12-2006
EVALUATION The submitter says that the select doesn't block if there is a channel registered with an intereset set of 0. The operating system is Windows XP and I checked 5.0u6 and it does block. We do have some known issues in this area with the Linux kernels (see 6371630 and 6403933) but these issues do not arise on Windows. It would be great if the submitter could follow-up with a small test case to help us diagnose this one. The second issue stems from the Selector implementation. Checking if a connection is writable is the same thing as checking if a connect has completed. As the submitter is registering for OP_WRITE before the connection is established it means the select will wakeup when the connection is established. There isn't a lot we can do about this although some re-design that could impact performance. A better approach is just only register for OP_READ or OP_WRITE once the connection is established.
24-05-2006