[GitHub] [kafka] showuon edited a comment on pull request #8712: KAFKA-10006: Don't create internal topics when LeaderNotAvailableException
showuon edited a comment on pull request #8712: URL: https://github.com/apache/kafka/pull/8712#issuecomment-652177809 Thanks for the comments, @abbccdda . I've address your comments in this commit: https://github.com/apache/kafka/pull/8712/commits/4b57a606a3834323302b6d3d33ab95e5b88d183b What I did in this commit are: 1. simplifiy code 2. use the existing topic name in tests, instead of creating a new topic name: `leaderNotAvailableTopic` 3. use `numRetries` to indicate we are trying to go beyond the retry limit This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [kafka] showuon edited a comment on pull request #8712: KAFKA-10006: Don't create internal topics when LeaderNotAvailableException
showuon edited a comment on pull request #8712: URL: https://github.com/apache/kafka/pull/8712#issuecomment-650135514 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [kafka] showuon edited a comment on pull request #8712: KAFKA-10006: Don't create internal topics when LeaderNotAvailableException
showuon edited a comment on pull request #8712: URL: https://github.com/apache/kafka/pull/8712#issuecomment-650135514 hi @abbccdda , I've fixed the issue. What I did in the final commit are: 0. Revert the unnecessary changes 1. Return the `topicsNotReady` to `makeReady` including `tempUnknownTopics`, and not create topic to wait for next retry 2. Empty `tempUnknownTopics` will be created in each retry, since the `topicsNotReady` now includes `tempUnknownTopics` (can check below diagram) 3. add 2 more tests to total test 3 cases: 3.1 shouldCreateTopicWhenTopicLeaderNotAvailableAndThenTopicNotFound 3.2 shouldCompleteValidateWhenTopicLeaderNotAvailableAndThenDescribeSuccess 3.3 shouldThrowExceptionWhenKeepsTopicLeaderNotAvailable Below is the sequence diagram for `makeReady`. Hope it's clear for what I did. Thanks. https://user-images.githubusercontent.com/43372967/85853920-ee33fe00-b7e5-11ea-8710-6bdc21bf44e7.png;> This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [kafka] showuon edited a comment on pull request #8712: KAFKA-10006: Don't create internal topics when LeaderNotAvailableException
showuon edited a comment on pull request #8712: URL: https://github.com/apache/kafka/pull/8712#issuecomment-650135514 hi @abbccdda , I've fixed the issue. What I did in the final commit are: 0. Revert the unnecessary changes 1. Return the `topicsNotReady` to `makeReady` including `tempUnknownTopics`, and not create topic to wait for next retry 2. Empty `tempUnknownTopics` will be created in each retry, since the `topicsNotReady` now includes `tempUnknownTopics` (can check below diagram) 3. add 2 more tests to total test 3 cases: 3.1 shouldCreateTopicWhenTopicLeaderNotAvailableAndThenTopicNotFound 3.2 shouldCompleteValidateWhenTopicLeaderNotAvailableAndThenDescribeSuccess 3.3 shouldThrowExceptionWhenKeepsTopicLeaderNotAvailable Below is the sequence diagram for `makeReady`. Hope it's clear for what I did. Thanks. https://user-images.githubusercontent.com/43372967/85853736-a4e3ae80-b7e5-11ea-84b5-47984ee170bb.png;> This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [kafka] showuon edited a comment on pull request #8712: KAFKA-10006: Don't create internal topics when LeaderNotAvailableException
showuon edited a comment on pull request #8712: URL: https://github.com/apache/kafka/pull/8712#issuecomment-650135514 hi @abbccdda , I've fixed the issue. What I did in the final commit are: 0. Revert the unnecessary changes 1. Return the `topicsNotReady` to `makeReady` including `tempUnknownTopics`, and not create topic to wait for next retry 2. Empty `tempUnknownTopics` will be created in each retry, since the `topicsNotReady` now includes `tempUnknownTopics` (can check below diagram) 3. add 2 more tests to total test 3 cases: 3.1 shouldCreateTopicWhenTopicLeaderNotAvailableAndThenTopicNotFound 3.2 shouldCompleteValidateWhenTopicLeaderNotAvailableAndThenDescribeSuccess 3.3 shouldThrowExceptionWhenKeepsTopicLeaderNotAvailable Below is the sequence diagram for `makeReady`. Hope it's clear for what I did. Thanks. https://user-images.githubusercontent.com/43372967/85853165-a06ac600-b7e4-11ea-888e-ac98dc26cca0.png;> This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [kafka] showuon edited a comment on pull request #8712: KAFKA-10006: Don't create internal topics when LeaderNotAvailableException
showuon edited a comment on pull request #8712: URL: https://github.com/apache/kafka/pull/8712#issuecomment-649896512 hi @abbccdda , Last night before I went to sleep, I kept thinking about your question: > Why do we need allTopicsToDescribe? Then I found my change has 1 small logic flaw, that is if the topic after `LeaderNotAvailableException` thrown, it got `UnknownTopicException`, we won't create topic for it. I'll fix it, and then add 2 more tests for 2 different situation. Will let you know. Thanks. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [kafka] showuon edited a comment on pull request #8712: KAFKA-10006: Don't create internal topics when LeaderNotAvailableException
showuon edited a comment on pull request #8712: URL: https://github.com/apache/kafka/pull/8712#issuecomment-649896512 hi @abbccdda , Last night before I went to sleep, I kept thinking about your question: > Why do we need allTopicsToDescribe? Then I found my change has 1 small logic flaw, that if the topic after `LeaderNotAvailableException`, it got `UnknownTopicException`, we won't create topic for it. I'll fix it, and then add 2 more tests for 2 different situation. Will let you know. Thanks. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [kafka] showuon edited a comment on pull request #8712: KAFKA-10006: Don't create internal topics when LeaderNotAvailableException
showuon edited a comment on pull request #8712: URL: https://github.com/apache/kafka/pull/8712#issuecomment-648846927 Hi @ableegoldman , thanks for the good suggestion! I've updated in this commit: https://github.com/apache/kafka/pull/8712/commits/f378c34d10c57d796412ac946f867e5787f93af0. What I did in this commit is: 1. rewrite the test by `EasyMock`, to make the tests better, and because of this test rewrite, I found a bug that I missed before, which is that when we retried the `describeTopics` in `getNumPartitions`, we should also add the `tempUnknownTopics` into the to-be-describe list since they also needed to be retried. Thanks for the suggestion! 2. remove unneeded hack in MockAdminClient 3. rename the variable name `leaderNotAvailableTopics` to `tempUnknownTopics` 4. use `isEmpty()` to be consistent Thank you. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
