[ 
https://issues.apache.org/jira/browse/KAFKA-1282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14097047#comment-14097047
 ] 

nicu marasoiu commented on KAFKA-1282:
--------------------------------------

Traversing is quite cheap and can be done every 1000 selects.
The intent of your suggestion is to optimize, I understand, but the effects is 
a different behavior as I feel it (changes the expiration by time and switches 
it to an expiration by connection count), and to a low performance benefit (I 
think traversing is much cheaper than blocking close on each channel, that 
would happen either way).
The idea of limited connection count can be used complementary to the existing 
traversing, but if you mean to take out the traversing every n selects, that 
changes the expiration by time and switches it to an expiration by connection 
count - is it an agreed requirements change with [~junrao]? I must warn that it 
is dangerous in my view to configure a maximum connection count per broker, 
because in event many brokers go down, and many clients need to use the system, 
this connection thrashing would not help anybody, and be a worse effect than 
not having this connection expiration at all, in such a scenario, relevant to a 
highly available system.

> 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: nicu marasoiu
>              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)

Reply via email to