Hi, I am sorry, but traversing will be limited to the connections that will actually be expired, so there is no traversing of non-expiring connections (please see the detailed example below).
I do agree on the other hand that there will be a polling on the first entry until it expires, but this is how we can implement the requirement exactly as intended (expiration taking into account just time as per stated "stale connections" issue, not connection count or activity as well), and it can be done every 1000 selects.
If we want to protect brokers from becoming zombies, this is a different concern I feel. However, I completely agree that we can do the LRU limiting as well to avoid zombeing (as part of this jira or another one). Both mechanisms to expire can be at work and solve both problems with no overhead in doing so (there would just be 2 contexts in which an evict+close would be performed, if we do not count the evict done in a normal close call).
Jun Rao, Jay Kreps, what do you think?
Say the server hold 100K connections. Say 100 connections are not used in the last 10 minutes.
What the program does (or I will make sure it does) is just iterate through the first 101 connections, the first 100 will be expired and it will stop at number 101.
I think this is an exact achievement of expected behavior of the jira task, as intended, and there is no performance penalty to that really!
I will rewrite with a loop /(tail-)recursive function, to check the first entry, and if stale call close (which also does a remove on the map anyways), and retry the next entry. This would be to avoid copying of the first 100 selectionKeys as well as to avoid any overhead/eagerness in map function.