JDK-6403933 : (se) Selector doesn't block on Selector.select(timeout) (lnx)
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.nio
  • Affected Version: 9.0pe,1.4.2_13,6
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux,linux_redhat_8.0
  • CPU: generic,x86
  • Submitted: 2006-03-24
  • Updated: 2011-03-28
  • Resolved: 2007-04-17
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7
6u4Fixed 7 b12Fixed
Related Reports
Duplicate :  
JDK-6525190 - (se) Selector implementation violates spec by always returning (lnx)
Relates :  
JDK-6595055 - orbd consumes 100% cpu
Description
Pl. see comments
Comments
EVALUATION For those using the 2.6 kernel, this issue has been fixed in jdk7 b12. This fix will also be included in a future jdk6 update (probably 6.0u3). The changes to resolve this for the poll based SelectorProvider (used on the 2.4) are more complex and will be done in conjunction with 6429204 for a later build.
08-03-2007
WORK AROUND -- The workaround to this issue is to cancel the key and flush it from the Selector (by invoking the selectNow method).
16-02-2007
EVALUATION This bug needs to be resolved for dolphin to avoid the Selector spinning when the connection is reset. If the interest set is 0 then this can be solved by unregistering the file descriptor (and re-registering if the interest set is changed). When the interest set is non-0 then the POLLHUP/POLLERR will need to be translated to OP_READ or OP_WRITE events in the ready set to allow the application a chance to see the IOException.
05-05-2006
EVALUATION -- This is an issue with poll (and epoll) on Linux. If a file descriptor for a connected socket is polled with a request event mask of 0, and if the connection is abruptly terminated (RST) then the poll wakes up with the POLLHUP (and maybe POLLERR) bit set in the returned event set. The implication of this behaviour is that Selector will wakeup and as the interest set for the SocketChannel is 0 it means there aren't any selected events and the select method returns 0.
28-03-2006
EVALUATION Committed workaround: Checking in ByteBufferInputStream.java; /cvs/glassfish/appserv-http-engine/src/java/com/sun/enterprise/web/connector/grizzly/ByteBufferInputStream.java,v <-- ByteBufferInputStream.java new revision: 1.9; previous revision: 1.8 done I'm not closing the bug yet, as I still think the problem is not in Grizzly. Making it as a p4 and will re-assign once we confirm it is a VM bog.
27-03-2006
EVALUATION Applied the following workaround from Charlie: if (SelectionKey != null) { // the key you registered on the temporary selector SelectionKey.cancel(); // cancel the SelectionKey that was registered with the temporary selector // flush the cancelled key temporarySelector.selectNow(); } which is safe. Now everything works fine.
24-03-2006
WORK AROUND Trash wasted Selector, creates a new one.
24-03-2006