-
Notifications
You must be signed in to change notification settings - Fork 14.1k
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
KAFKA-18399 Remove ZooKeeper from KafkaApis (10/N): ALTER_CLIENT_QUOTAS, handleAllocateProducerIdsRequest #18465
base: trunk
Are you sure you want to change the base?
Conversation
…dleAllocateProducerIdsRequest
requestHelper.sendResponseMaybeThrottle(request, throttleTimeMs => | ||
new AllocateProducerIdsResponse(producerIdsResponse.setThrottleTimeMs(throttleTimeMs))) | ||
) | ||
throw KafkaApis.shouldNeverReceive(request) |
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.
I think we shouldn't handle it like this - this is one of the request types that is only handled by the controller listener (now that zk is gone):
"listeners": ["zkBroker", "controller"]
So, we should have generic logic that handles that automatically before it gets here. We can probably just delete this whole method.
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.
Same for handleAlterClientQuotasRequest
.
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.
So, we should have generic logic that handles that automatically before it gets here. We can probably just delete this whole method.
totally agree that we should have a generic logic for those zk-related handler. The socket server can reject the zk-related requests automatically, and we can rewrite maybeForwardToController
to throw KafkaApis.shouldAlwaysForward
automatically. With those change, those zk-related handlers can be deleted directly.
In short, the line case ApiKeys.ALLOCATE_PRODUCER_IDS => handleAllocateProducerIdsRequest(request)
can be removed.
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, exactly. We can also remove the zk listener from the json files and the socket server will automatically do the right thing, I believe (i.e. it already has logic for that).
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 can also remove the zk listener from the json files
https://issues.apache.org/jira/browse/KAFKA-18399
Committer Checklist (excluded from commit message)