Hey, I noticed that there was no discussion for the last 10 days, but I couldn't find the vote thread. Is there one that I'm missing?
Gwen On Wed, Sep 22, 2021 at 4:58 AM Magnus Edenhill <mag...@edenhill.se> wrote: > Den tis 21 sep. 2021 kl 06:58 skrev Colin McCabe <cmcc...@apache.org>: > > > On Mon, Sep 20, 2021, at 17:35, Feng Min wrote: > > > Thanks Magnus & Colin for the discussion. > > > > > > Based on KIP-714's stateless design, Client can pretty much use any > > > connection to any broker to send metrics. We are not associating > > connection > > > with client metric state. Is my understanding correct? If yes, how > about > > > the following two scenarios > > > > > > 1) One Client (Client-ID) registers two different client instance id > via > > > separate registration. Is it permitted? If OK, how to distinguish them > > from > > > the case 2 below. > > > > > > > Hi Feng, > > > > My understanding, which Magnus can clarify I guess, is that you could > have > > something like two Producer instances running with the same client.id > > (perhaps because they're using the same config file, for example). They > > could even be in the same process. But they would get separate UUIDs. > > > > I believe Magnus used the term client to mean "Producer or Consumer". So > > if you have both a Producer and a Consumer in your application I would > > expect you'd get separate UUIDs for both. Again Magnus can chime in > here, I > > guess. > > > > That's correct. > > > > > > > 2) How about the client restarting? What's the expectation? Should the > > > server expect the client to carry a persisted client instance id or > > should > > > the client be treated as a new instance? > > > > The KIP doesn't describe any mechanism for persistence, so I would assume > > that when you restart the client you get a new UUID. I agree that it > would > > be good to spell this out. > > > > > Right, it will not be persisted since a client instance can't be restarted. > > Will update the KIP to make this clearer. > > /Magnus > -- Gwen Shapira Engineering Manager | Confluent 650.450.2760 | @gwenshap Follow us: Twitter | blog
