-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
close client connectionon tooManyRequest and internal-server error #274
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Change looks good, let's wait for the dependent PR to be merged and then rebase this one.
@@ -61,6 +64,13 @@ | |||
|
|||
private final CompletableFuture<Void> connectionFuture = new CompletableFuture<Void>(); | |||
private final Semaphore pendingLookupRequestSemaphore; | |||
private final Timer timer; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should already have a ScheduledExecutor
instance around that we can use.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
actually we don't have ScheduledExecutor
instance around. should we create one?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that's true, then we could use the eventLoop
associated with the netty channel to schedule the task.
(If we use a timer per connection, it will create a different thread for each of them)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, that's right. fixed it.
4a35d90
to
90ce6e3
Compare
@@ -61,6 +65,13 @@ | |||
|
|||
private final CompletableFuture<Void> connectionFuture = new CompletableFuture<Void>(); | |||
private final Semaphore pendingLookupRequestSemaphore; | |||
private final EventLoopGroup eventLoopGroup; | |||
private Timeout timeoutTask; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not used anymore
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
…pache#274) Fixes apache#273 When KoP handles metadata requests, it only checks the config allowAutoTopicCreation but not the same field in the metadata request. Then it causes that AdminClient#describeTopics returns a success result even if the topics don't exist and topics will be created automatically. So this PR adds the check for metadata request's allowAutoTopicCreation field and the test for AdminClient#describeTopics.
Motivation
Client creates a dedicated binary-proto lookup connection with one broker and there could be a possibility
In that case, client should close the existing connection and try to recreate which may end up with new connection with other broker and do successful lookup.
Modifications
check serverError and take appropriate action
Result
Client can recreate connection with different broker if it is not able to getting successful response from one particular broker.
NOTE
I have created this PR on top of #181 changes as it requires ServerSide throttling.
So, this PR depends on #181 and we need to merge #181 first.