[jira] [Commented] (KAFKA-14394) BrokerToControllerChannelManager has 2 separate timeouts

["Ron Dagostino (Jira)" <ji...@apache.org>]

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

Ron Dagostino commented on KAFKA-14394:
---------------------------------------

As per https://github.com/apache/kafka/pull/9564#discussion_r527326231, we do want infinite retries for when the broker sends AlterPartition requests.  Closing this issue as the code is correct.

> BrokerToControllerChannelManager has 2 separate timeouts
> --------------------------------------------------------
>
>                 Key: KAFKA-14394
>                 URL: https://issues.apache.org/jira/browse/KAFKA-14394
>             Project: Kafka
>          Issue Type: Task
>            Reporter: Ron Dagostino
>            Priority: Major
>
> BrokerToControllerChannelManager uses `config.controllerSocketTimeoutMs` as its default `networkClientRetryTimeoutMs` in general, but it does accept a second `retryTimeoutMs`, value -- and then there is exactly one place where second timeout is used: within BrokerToControllerRequestThread.  Is this second, separate timeout actually necessary, or is it a bug (in which case the two timeouts should be the same).  Closely related to this is the case of AlterPartitionManager, which sends Long.MAX_VALUE as the retryTimeoutMs value when it instantiates its instance of BrokerToControllerChannelManager.  Is this Long.MAX_VALUE correct, when in fact `config.controllerSocketTimeoutMs` is being used as the other timeout?
> This is related to https://issues.apache.org/jira/projects/KAFKA/issues/KAFKA-14392 and the associated PR, https://github.com/apache/kafka/pull/12856



--
This message was sent by Atlassian Jira
(v8.20.10#820010)