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 > > >
