I agree the formation in the pull request is the cleanest. Thanks
On Mon, Dec 11, 2017 at 5:05 PM, Ewen Cheslack-Postava <e...@confluent.io> wrote: > I did, but it doesn't seem to gain much. In order to still avoid having > these intermediate states, you'd still need a latch and then to block any > calls to the root resource until you could connect. It would allow starting > up the rest of the worker, but if it's just going to fail and put the > worker into a bad state anyway, that doesn't seem to help much. > > The alternative of just returning incomplete info didn't seem worth the > hassle for users since if you can't connect to the cluster to get the > cluster ID, none of the other APIs would be useful either (you're not going > to be able to write new connector configs, asking for connector state will > give you empty data since you wouldn't be able to load the configs or > status topics, etc). > > -Ewen > > On Mon, Dec 11, 2017 at 4:35 PM, Ted Yu <yuzhih...@gmail.com> wrote: > > > Looks good overall. > > > > Currently lookupKafkaClusterId() is called synchronously. Have you > > considered making the call asynchronous (normally the GET / request comes > > sometime after worker start) ? > > > > Thanks > > > > On Mon, Dec 11, 2017 at 3:40 PM, Ewen Cheslack-Postava < > e...@confluent.io> > > wrote: > > > > > I'd like to start discussion on a simple KIP to expose Kafka cluster ID > > > info in the Connect REST API: > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP- > > > 238%3A+Expose+Kafka+cluster+ID+in+Connect+REST+API > > > > > > Hopefully straightforward, though there are some details on how this > > > affects startup behavior that might warrant discussion. > > > > > > -Ewen > > > > > >
