I’m implementing a Non-Blocking HTTP server in Java and decided to use pure Java NIO. I’m combining a NIO Selector with a small thread pool to perform the operations indicated by the selector.
Leaving the system choose the default selector (tested in Linux 2.6 epoll and Mac OS Snow Leo KQueue) and using Selector.select(TIMEOUT); I get the thread pool in Monitor state (waiting for acquire a Monitor) while the main thread (running the selector event loop) stay always running. In some cases the Monitor state (the time waiting for acquire a Monitor) wastes more than 10s.
Using the following approach causes the main thread spend most of its time sleeping, less (almost nothing Monitor state for pooled threads) and better throughput (1k requests handled per second):
while (true) {
Thread.sleep(IOLoop.SELECT_TIMEOUT);
if (selector.selectNow() == 0)
continue;
Iterator<SelectionKey> iter = selector.selectedKeys().iterator();
//...
}
Anyone there know the impacts/risks of this decision, or how to alleviate/eliminate the expended time trying to acquire an object Monitor using the selector select method with timeout?
Thanks.
Selector api and sun’s impl are horrible.
The document allows you to have multiple threads blocking on one selector’s select(), but there is no point doing that. You should have only one thread blocked on one selector.select().
And the actual impl simply does
syncrhonized(this)in select() to achieve thread safety.It’s like the Vector and Hashtable of the old days of excessive synchronization.
They should have simply exposed low level primitive non blocking methods, without wrapping them in so many nanny abstractions – average programmers won’t use selectors, and those who do can take care of themselves.