[
https://issues.apache.org/jira/browse/KAFKA-1282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14098324#comment-14098324
]
Nicolae Marasoiu edited comment on KAFKA-1282 at 8/15/14 8:35 AM:
------------------------------------------------------------------
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.
[~junrao], [~jkreps], 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.
was (Author: nmarasoiu):
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.
[~junrao], [~jkreps], 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!
> Disconnect idle socket connection in Selector
> ---------------------------------------------
>
> Key: KAFKA-1282
> URL: https://issues.apache.org/jira/browse/KAFKA-1282
> Project: Kafka
> Issue Type: Bug
> Components: producer
> Affects Versions: 0.8.2
> Reporter: Jun Rao
> Assignee: Neha Narkhede
> Labels: newbie++
> Fix For: 0.9.0
>
> Attachments:
> kafka-1282__Disconnect_idle_socket_connection_in_Selector.patch
>
>
> To reduce # socket connections, it would be useful for the new producer to
> close socket connections that are idle. We can introduce a new producer
> config for the idle time.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
