Handle coordinator leader changes for segments view

[surekhasaharan]

Affected Version

Druid 0.16

Description

The web-console's Datasources view and the Segments view would not work if there is a leader change in the background. It's because the backend API which invokes the coordinator to get segments does not handle leader changes.

The workaround for now would be to restart the coordinator, so that router connects to the current leader.

[himanshug]

haven't looked at the code, but relevant part should just use DruidLeaderClient class that is meant to be used for talking to coordinator/overlord and handles all that.

[surekhasaharan]

DruidLeaderClient#goAsync does not handle leadership changes, so callers of that API i.e. SystemSchema need to retry on http response 307/Temporary Redirect

[himanshug]

sorry, glad to know that DruidLeaderClient is already being used , wasn't aware of DruidLeaderClient#goAsync which purposefully skips managing the request lifecycle and consequently doesn't do the redirects itself.

goAsync(..) use cases can probably be replaced to use go(..) with use of a version of InputStreamResponseHandler that preserves the HTTP response code .

[surekhasaharan]

goAsync is supposed to be non-blocking, it doesn't do a get() on the future, it takes a BytesAccumulatingResponseHandler. I was thinking of doing the retries from the callers of goAsync on exception in future.get(), not sure if there's a better solution.

[jihoonson]

goAsync(..) use cases can probably be replaced to use go(..) with use of a version of InputStreamResponseHandler that preserves the HTTP response code .

I think this is the right way we should go in the future.

[jihoonson]

Taking out this issue from 0.17.0. The workaround could be refreshing the browser after the leader has changed.

[himanshug]

I'm gonna implement

goAsync(..) use cases can probably be replaced to use go(..) with use of a version of InputStreamResponseHandler that preserves the HTTP response code .

and remove goAsync(..) .