Ismael, Thanks for the proposal. It looks good overall. Just a comment below.
We are adding the following interface in ClusterListener and Cluster includes all brokers' endpoint and the metadata of topic partitions. void onClusterUpdate(Cluster cluster); On the broker side, will that method be called when there is broker or topic/partition change in metadata cache? Another thing is that Cluster only includes one endpoint. This makes sense for the client. However, on the broker side, it's not clear which endpoint should be used. In general, I am not sure how useful it is for serializers, interceptors, metric reporters to know all brokers endpoints and topic/partition metadata. I was thinking we could instead pass in sth like a ClusterResourceMeta and just include the clusterId for now. This way, we can guarantee that onClusterUpdate() will only be called once and it's easier to implement on the broker side. Jun On Wed, Aug 31, 2016 at 1:24 AM, Ismael Juma <ism...@juma.me.uk> wrote: > Thanks for the feedback Guozhang. Comment inline. > > On Wed, Aug 31, 2016 at 2:49 AM, Guozhang Wang <wangg...@gmail.com> wrote: > > > About logging / debugging with the cluster id: I think the random UUID > > itself may not be very helpful for human-readable debugging information, > > and we'd better use the cluster name mentioned in future work in logging. > > > > We can also add the human-readable value once it's available. However, the > random UUID is still useful now. After all, we use Git commit hashes in > many places and they are significantly longer than what we are proposing > here (40 instead of 22 characters) . When comparing by eye, one can often > just look at the first few characters to distinguish. Does that make sense? > > Ismael >
