Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / May 2006

Tip: Looking for answers? Try searching our database.

NIO - Selector.select() doesn't block

Thread view: 
Domagoj Klepac - 07 May 2006 17:04 GMT
Anyone worked with NIO (Java 1.5)?

I cannot seem to figure this one - the example from the web works as
expected, but my code doesn't, and I can't find the part which makes
the difference.

My selector.select() or selector.select(timeout) work as expected
until the connection is established. After that, they return 0
immediately. That results in 100% processor usage during the
connection. After the connection(s) is/are closed, select() blocks
again as expected.

Except for 100% processor usage, my program works fine - bytes get
read and written correctly.

Now, I've googled and googled and I've found several possible causes
which don't seem to apply:
- it's not a bug in NIO - all such bugs seem to be fixed by 1.5
- I'm removing the key from the ready set after processing via
iterator.remove()
- I'm not interrupting select with selector.wakeup() (at least not
until shutdown)
- my channels are not blocking, and I'm registering channels with
selector from the same thread that calls selector.select().

From what I know, selector.select() should return 0 only when
interrupted by selector.wakeup(). Selector.select(timeout) should
return 0 only if interrupted by selector.wakeup() or after the timeout
expires.

Are there any other cases where selector.select() returns immediately?

               Domchi
Stefan Schulz - 07 May 2006 18:57 GMT
Make sure you clear() the selected set once you are done with it. If
there are still keys in that set, select() will return immediatly with
those keys.
Domagoj Klepac - 07 May 2006 19:18 GMT
>Make sure you clear() the selected set once you are done with it. If
>there are still keys in that set, select() will return immediatly with
>those keys.

Shouldn't in that case select() return value greater than 0?

In any case, I've just tried explicitly clearing the set, and the
problem persists. :(

               Domchi
Stefan Schulz - 07 May 2006 19:43 GMT
> >Make sure you clear() the selected set once you are done with it. If
> >there are still keys in that set, select() will return immediatly with
[quoted text clipped - 4 lines]
> In any case, I've just tried explicitly clearing the set, and the
> problem persists. :(

Hmm, can you provide us with an self-contained example that exhibits
the problem?
Domagoj Klepac - 07 May 2006 22:47 GMT
>> >Make sure you clear() the selected set once you are done with it. If
>> >there are still keys in that set, select() will return immediatly with
[quoted text clipped - 7 lines]
>Hmm, can you provide us with an self-contained example that exhibits
>the problem?

Hmph.

I found the problem while I was making the simplified example for
posting. I was registering for OP_CONNECT after the connection was
already established. Though I'm not quite sure why that breaks the
selector. I would expect either some kind of exception or acceptable
key in the ready set (in that case select() should return 1 instead
0).

               Domchi
Remon van Vliet - 09 May 2006 19:11 GMT
> Anyone worked with NIO (Java 1.5)?
>
[quoted text clipped - 29 lines]
>
>                Domchi

Which operations do you have registered? If you register OP_WRITE the
behaviour you describe is correct because the OP_WRITE is (almost) always
ready, and thus select() always returns immediately, removing the key from
the selectedKeys() collection is not related to your problem. Please post
your registration code and your select loop if the problem is not fixed by
removing the OP_WRITE registration.

On that note, OP_WRITE should only be added to the interested ops set if you
are sure you actually have something to write.

Regards,

- Remon
Remon van Vliet - 09 May 2006 19:13 GMT
>> Anyone worked with NIO (Java 1.5)?
>>
[quoted text clipped - 43 lines]
>
> - Remon

never mind, i missed the post where you found the issue ;)
Gordon Beaton - 10 May 2006 07:36 GMT
> On that note, OP_WRITE should only be added to the interested ops
> set if you are sure you actually have something to write.

And not even then, in most cases, since the socket is almost always
writeable without blocking anyway. It's only necessary to register
OP_WRITE after a previous write operation has failed (written 0 or
short), and then only until the write succeeds.

/gordon

Signature

[  do not email me copies of your followups  ]
g o r d o n + n e w s @  b a l d e r 1 3 . s e



Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2009 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.