United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4850373 : Blocking Selector stops Blocking occasionally

Details
Type:
Bug
Submit Date:
2003-04-17
Status:
Closed
Updated Date:
2004-04-28
Project Name:
JDK
Resolved Date:
2004-02-06
Component:
core-libs
OS:
windows_xp,windows_2000
Sub-Component:
java.nio
CPU:
x86
Priority:
P3
Resolution:
Fixed
Affected Versions:
1.4.2,1.4.2_02
Fixed Versions:
1.4.2_05 (05)

Related Reports
Backport:

Sub Tasks

Description

Name: nt126004			Date: 04/17/2003


FULL PRODUCT VERSION :
java version "1.4.2-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-beta-b19)
Java HotSpot(TM) Client VM (build 1.4.2-beta-b19, mixed mode)

FULL OS VERSION :
Microsoft Windows 2000 [Version 5.00.2195]

A DESCRIPTION OF THE PROBLEM :
Blocking Selector stops Blocking occasionally.

It would appear that when wakeup() is called at a certain point then the selector.select() method starts returning instantly with no selected keys from then on.

This problem is difficult to consistantly reproduce hence it is difficult to track down the exact cause of the problem.

It is a very serious problem for anyone using blocking io as the cpu usage jumps to 100%.

As it is difficult to produce a small test case I have done some research to help find the bug:

* once the problem is occuring the following debug information is available:
keys == {key with interestOps == 1 fd == 1788}
cancelledKeys == {}
sourceFD == 1552
sinkFD == 1600
interruptTriggered == false
timeout == -1
threads == {}
2 channels
exceptIDs == {0, 0, 0, ...}
readIDs == {1, 1552, 1788, 0, 0, 0, ...}
writeIDs == {0, 1788, 0, 0, 0, ...}

* the trace through the code of WindowsSelectorImpl doSelect(long aTimout)
1) calls processDeregisterQueue();
2) calls adjustThreadsCount();
3) calls finishLock.reset();
4) calls startLock.startThreads();
5) calls begin();
6) calls subSelector.poll(); (this doesn't block, I guess this is the problem)
7) calls end();
8) calls resetWakeupSocket();
9) calls finishLock.checkForException();
10) calls processDeregisterQueue();
11) calls updateSelectedKeys();
12) returns 0

Note the same problem also exists in JDK1.4.1_02 (I though maybe the synchronization changes would have fixed it, however they didn't)
This is a replacement bug for review ID: 183301 (review id 183301 is no longer important)

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Difficult to provide a test case due to the nature of the problem.
I have only been able to reproduce the problem when wakeup() has been called.
It is too difficult to establish at what point in select() the code is up to when wakeup() causes the problem.

EXPECTED VERSUS ACTUAL BEHAVIOR :
when no keys are ready to be selected select() to block again until keys become ready for selection or wakeup/interrupt is called.
select() returns no keys without blocking

REPRODUCIBILITY :
This bug can be reproduced occasionally.

---------- BEGIN SOURCE ----------
Difficult to make small test case, however we are able to reproduce the problem occasionally with our actual code, hence I can provide more debug info if what is provided in the desription is not enough.  This is a very serious problem for everone relying on select() to block, hence I will try to answer questions about this ASAP.
---------- END SOURCE ----------
(Review ID: 183670) 
======================================================================

                                    

Comments
EVALUATION

Not for mantis.
###@###.### 2003-04-22

Selector spin can be caused by these two situations, both of which
are the result of ready to write being identical to ready to connect
at the native level.

1. The channel is not connected, the key interested in writing and
   the key ready for writing. Because the key is ready for something it
   is interested in, the select operation returns immediately, but the
   key is not marked as ready for write, because the channel is not
   in the connected state, therefore the key was not added to the selected
   set. So the selector spins and returns 0.

2. The channel is connected, the key interested in connecting and 
   the key ready for connecting. Because the key is ready for something it
   is interested in, the select operation returns immediately, but the
   key is not marked as ready to connect, because the channel is already
   connected. Therefore the key was not added to the selected set, the
   selector spins and returns 0.

###@###.### 2003-08-13


There is a timing issue in the wakeup mechanism which arises when the
wakeup is observed before the "wakeup byte" is received. Specifically
WindowsSelectorImpl.doSelect will reset the wakeup socket when
interruptedTriggered is set. If the wakeup byte hasn't been received
(nagle is enabled by default for example) then all subsequent calls
to select will return immediately. 
###@###.### 2004-01-07
                                     
2004-01-07
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
1.4.2_05
generic
tiger-beta2

FIXED IN:
1.4.2_05
tiger-beta2

INTEGRATED IN:
1.4.2_05
tiger-b38
tiger-beta2

VERIFIED IN:
1.4.2_05


                                     
2004-06-14



Hardware and Software, Engineered to Work Together