[
https://issues.apache.org/jira/browse/KAFKA-13033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luke Chen updated KAFKA-13033:
------------------------------
Description:
In KIP-699, we add some handler to handle different types of operation. In the
`handleError`, we didn't make the `COORDINATOR_NOT_AVAILABLE` as unmapped, to
do a re-lookup. In
[DescribeTransactionsHandler|https://github.com/apache/kafka/blob/trunk/clients/src/main/java/org/apache/kafka/clients/admin/internals/DescribeTransactionsHandler.java#L172-L186],
there's already explained by [~hachikuji] why `COORDINATOR_NOT_AVAILABLE` and
`NOT_COORDINATOR` should be listed in unmapped, and
`COORDINATOR_LOAD_IN_PROGRESS` should not.
{code:java}
case COORDINATOR_LOAD_IN_PROGRESS:
// If the coordinator is in the middle of loading, then we just need to
retry
log.debug("DescribeTransactions request for transactionalId `{}` failed
because the " +
"coordinator is still in the process of loading state. Will retry",
transactionalIdKey.idValue);
break;
case NOT_COORDINATOR:
case COORDINATOR_NOT_AVAILABLE:
// If the coordinator is unavailable or there was a coordinator change,
then we unmap
// the key so that we retry the `FindCoordinator` request
unmapped.add(transactionalIdKey);
log.debug("DescribeTransactions request for transactionalId `{}` returned
error {}. Will attempt " +
"to find the coordinator again and retry",
transactionalIdKey.idValue, error);
break;
{code}
We should be consistent with it. Fix it, add logs and comments, and also update
the tests.
was:
In KIP-699, we add some handler to handle different types of operation. In the
`handleError`, we didn't make the `COORDINATOR_NOT_AVAILABLE` as unmapped, to
do a re-lookup. In [DescribeTransactionsHandler|#L172-L186],], there's already
explained by [~hachikuji] why `COORDINATOR_NOT_AVAILABLE` and `NOT_COORDINATOR`
should be listed in unmapped, and `COORDINATOR_LOAD_IN_PROGRESS` should not.
{code:java}
case COORDINATOR_LOAD_IN_PROGRESS:
// If the coordinator is in the middle of loading, then we just need to
retry
log.debug("DescribeTransactions request for transactionalId `{}` failed
because the " +
"coordinator is still in the process of loading state. Will retry",
transactionalIdKey.idValue);
break;
case NOT_COORDINATOR:
case COORDINATOR_NOT_AVAILABLE:
// If the coordinator is unavailable or there was a coordinator change,
then we unmap
// the key so that we retry the `FindCoordinator` request
unmapped.add(transactionalIdKey);
log.debug("DescribeTransactions request for transactionalId `{}` returned
error {}. Will attempt " +
"to find the coordinator again and retry",
transactionalIdKey.idValue, error);
break;
{code}
We should be consistent with it. Fix it, add logs and comments, and also update
the tests.
> coordinator not available error should cause add into unmap list to do a new
> lookup
> -----------------------------------------------------------------------------------
>
> Key: KAFKA-13033
> URL: https://issues.apache.org/jira/browse/KAFKA-13033
> Project: Kafka
> Issue Type: Bug
> Affects Versions: 3.0.0
> Reporter: Luke Chen
> Assignee: Luke Chen
> Priority: Major
>
> In KIP-699, we add some handler to handle different types of operation. In
> the `handleError`, we didn't make the `COORDINATOR_NOT_AVAILABLE` as
> unmapped, to do a re-lookup. In
> [DescribeTransactionsHandler|https://github.com/apache/kafka/blob/trunk/clients/src/main/java/org/apache/kafka/clients/admin/internals/DescribeTransactionsHandler.java#L172-L186],
> there's already explained by [~hachikuji] why `COORDINATOR_NOT_AVAILABLE`
> and `NOT_COORDINATOR` should be listed in unmapped, and
> `COORDINATOR_LOAD_IN_PROGRESS` should not.
>
> {code:java}
> case COORDINATOR_LOAD_IN_PROGRESS:
> // If the coordinator is in the middle of loading, then we just need to
> retry
> log.debug("DescribeTransactions request for transactionalId `{}` failed
> because the " +
> "coordinator is still in the process of loading state. Will
> retry",
> transactionalIdKey.idValue);
> break;
> case NOT_COORDINATOR:
> case COORDINATOR_NOT_AVAILABLE:
> // If the coordinator is unavailable or there was a coordinator change,
> then we unmap
> // the key so that we retry the `FindCoordinator` request
> unmapped.add(transactionalIdKey);
> log.debug("DescribeTransactions request for transactionalId `{}` returned
> error {}. Will attempt " +
> "to find the coordinator again and retry",
> transactionalIdKey.idValue, error);
> break;
> {code}
> We should be consistent with it. Fix it, add logs and comments, and also
> update the tests.
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
