[
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:45 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. 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).
[~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!
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.
> 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)
