Using OP_CONNECT with Selector.select causes selector to fire repeatedly

[Alan Bateman]

Deven,

I'm busy at the moment and don't have time to write a detailed reply. 
However I think this one is just incorrect usage of the API that should 
be fixed by adding a warning or some clarification to the javadoc, not 
an implementation change. For example, if your test then the return 
value from connect is ignored and therefore the test is not handling the 
case where the connection is established immediately. Even if the 
connection is not established immediately then the test code that 
invokes finishConnect doesn't change interestOps, say to OP_READ for the 
case that it expects to read from the connection. I will get back to you 
when I can but I really think this one just requires adding something to 
the javadoc.

-Alan

On 09/05/2012 08:33, Deven You wrote:
> I suddenly realized this topic should be in nio-dev mailing list. 
> Please ignore previous mail.
>
> Thanks a lot!
>
> On 05/09/2012 03:26 PM, Deven You wrote:
>> Hi All,
>>
>> When start a simple server, listening on a port like 8765, which just 
>> accepts connections. We then register a non-blocking SocketChannel 
>> (the client) with a selector with interest in OP_CONNECT, so that we 
>> can use the selector to notify us when the channel is ready to finish 
>> connecting.
>>
>> We call client.connect and then selector.select in a loop. The 
>> selector fires and with the client channel in the selected-keys set 
>> and we call finishConnect() on the client's channel.
>>
>> Then the problem occurs:
>> The selector repeatedly fires with no entries in its selected-keys 
>> set, whereas it should block in the next select operation until there 
>> is at least one key in the selected-keys set.
>>
>> There is already a sun bug for this issue[1], when I looked into this 
>> sun bug I realize the second scenario of this sun bug is described 
>> very detailed by a duplicate sun bug[2].
>>
>> One way to solve this problem is let selector  reset the OP_CONNECT 
>> bit as 0 after the channel is connected for the corresponding key 
>> using key.interestOps(). I just make a patch[3] for this approach.
>>
>> Could anyone take a look at this patch to see if we could solve this 
>> problem in this way!
>>
>> [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4919127
>>
>> [2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4960791
>>
>> [3] http://cr.openjdk.java.net/~littlee/ojdk-317/webrev.00/ 
>> <http://cr.openjdk.java.net/%7Elittlee/ojdk-317/webrev.00/>
>>
>> Thanks a lot!
>> -- 
>> Best Regards,
>>
>> Deven
>
>
> -- 
> Best Regards,
>
> Deven

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20120509/5c04c1bf/attachment.html