Message4495

[Kevin]
> From what I can tell, the underlying problem here is that there is an
> implicit leak in the java Selector object related to lookback
> connections, that it uses for whatever reason. So perhaps the best
> workaround would be to introduce our own 'leak' that will cover up the
> java one :)
> 
> What if we had a poll pool (say that 10 times fast :)? The naive
> implementation would make sure we never created more poll objects (and
> hence selectors) than the maximum number of simultaneous calls to
> select, instead of creating as many as there are calls to select.

That's a (great idea)*10 :-)

I'm not 100% convinced it will work, because we won't be able to close()
the poll objects in the pool, which might create problems with
outstanding references to SocketChannels. This is because they cannot be
re-opened: there is no open() method on Selectors: they can only be
created with the static factory method
java.nio.channels.Selector.open(), which returns them already opened.

http://java.sun.com/j2se/1.5.0/docs/api/java/nio/channels/Selector.html#open()

But it's the best idea proposed so far to solve this problem.

I'm working on a patch now; more later today.