[
https://issues.apache.org/jira/browse/KAFKA-1935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15873850#comment-15873850
]
Dipen Patel commented on KAFKA-1935:
Hi,
I think that this is an interesting first issue for me to work on.
Please correct me if I am wrong, but from my understanding the issue we are
trying to solve here is ensuring that each coordinator node that we register
with the consumer's NetworkClient has a unique Id such that there are no
conflicts with the Id's of existing nodes already registered with the
consumer's NetworkClient. By ensuring that each coordinator node's Id is
unique, we will have successfully mimicked unique sockets for each coordinator
node.
If that is the issue, then I think that implementing a mechanism to
check whether an Id is currently assigned to a node would be an appropriate
solution. This mechanism could be implemented by writing a method in the
NetworkClient that queries the ClusterConnectionStates (a class containing a
Map of all nodes) to check whether the String Id is assigned. We would then
have to modify the KafkaClient interface to account for the new method added to
the NetworkClient. These changes would allow the AbstractCoordinator class to
use its ConsumerNetworkClient field to call the newly implemented method in the
NetworkClient. In the case that the Id is not available we increment the Id and
repeat the process of checking the Id's uniqueness. Does this proposal sound
viable?
Thanks
> Consumer should use a separate socket for Coordinator connection
>
>
> Key: KAFKA-1935
> URL: https://issues.apache.org/jira/browse/KAFKA-1935
> Project: Kafka
> Issue Type: Sub-task
>Reporter: Guozhang Wang
> Labels: newbie
>
> KAFKA-1925 is just a quick-fix of this issue, we need to let consumer to be
> able to create separate sockets for the same server for coordinator / broker
> roles.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)