Package org.apache.druid.rpc

Interface ServiceClient

  • All Known Implementing Classes:
    ServiceClientImpl
    public interface ServiceClient
    Mid-level client that provides an API similar to low-level HttpClient, but accepts RequestBuilder instead of Request, and internally handles service location and retries. In most cases, this client is further wrapped in a high-level client like OverlordClient.

    • Method Detail

      • asyncRequest

        <IntermediateType,​FinalType> com.google.common.util.concurrent.ListenableFuture<FinalType> asyncRequest​(RequestBuilder requestBuilder,
                                                                                                              org.apache.druid.java.util.http.client.response.HttpResponseHandler<IntermediateType,​FinalType> handler)
        Perform a request asynchronously. Unlike HttpClient.go(org.apache.druid.java.util.http.client.Request, org.apache.druid.java.util.http.client.response.HttpResponseHandler<Intermediate, Final>), the provided "handler" is only used for 2xx responses. Response codes 1xx, 4xx, and 5xx are retried with backoff according to the client's ServiceRetryPolicy. If attempts are exhausted, the future will fail with RpcException containing the most recently encountered error. Redirects from 3xx responses are followed up to a chain length of MAX_REDIRECTS and do not consume attempts. Redirects are validated against the targets returned by ServiceLocator: the client will only follow redirects to targets that appear in ServiceLocations. If the client encounters a redirect to an unknown target, or if a redirect loop or self-redirect is detected, it is treated as an unavailable service and an attempt is consumed. If the service is unavailable at the time an attempt is made, the client will automatically retry based on ServiceRetryPolicy.retryNotAvailable(). If true, an attempt is consumed and the client will try to locate the service again on the next attempt. If false, the call immediately returns ServiceNotAvailableException. If an exception occurs midstream after an OK HTTP response (2xx) then the behavior depends on the handler. If the handler has not yet returned a finished object, the service client will automatically retry based on the provided ServiceRetryPolicy. On the other hand, if the handler has returned a finished object, the service client will not retry. Behavior in this case is up to the caller, who will have already received the finished object as the future's resolved value. Resolves to HttpResponseException if the final attempt failed due to a non-OK HTTP server response. Resolves to ServiceNotAvailableException if the final attempt failed because the service was not available (i.e. if the locator returned an empty set of locations). Resolves to ServiceClosedException if the final attempt failed because the service was closed. This is different from not available: generally, "not available" is a temporary condition whereas "closed" is a permanent condition.