Package org.apache.kafka.clients.admin.internals

Interface AdminApiLookupStrategy<T>

All Known Implementing Classes:
AllBrokersStrategy, CoordinatorStrategy, PartitionLeaderStrategy, StaticBrokerStrategy
public interface AdminApiLookupStrategy<T>

  • Method Details

    • lookupScope

      ApiRequestScope lookupScope(T key)
      Define the scope of a given key for lookup. Key lookups are complicated by the need to accommodate different batching mechanics. For example, a `Metadata` request supports arbitrary batching of topic partitions in order to discover partitions leaders. This can be supported by returning a single scope object for all keys. On the other hand, `FindCoordinator` requests only support lookup of a single key. This can be supported by returning a different scope object for each lookup key. Note that if the ApiRequestScope.destinationBrokerId() maps to a specific brokerId, then lookup will be skipped. See the use of StaticBrokerStrategy in DescribeProducersHandler for an example of this usage.
      Parameters:
      key - the lookup key
      Returns:
      request scope indicating how lookup requests can be batched together

    • buildRequest

      org.apache.kafka.common.requests.AbstractRequest.Builder<?> buildRequest(Set<T> keys)
      Build the lookup request for a set of keys. The grouping of the keys is controlled through lookupScope(Object). In other words, each set of keys that map to the same request scope object will be sent to this method.
      Parameters:
      keys - the set of keys that require lookup
      Returns:
      a builder for the lookup request

    • handleResponse

      AdminApiLookupStrategy.LookupResult<T> handleResponse(Set<T> keys, org.apache.kafka.common.requests.AbstractResponse response)
      Callback that is invoked when a lookup request returns successfully. The handler should parse the response, check for errors, and return a result indicating which keys were mapped to a brokerId successfully and which keys received a fatal error (e.g. a topic authorization failure). Note that keys which receive a retriable error should be left out of the result. They will be retried automatically. For example, if the response of `FindCoordinator` request indicates an unavailable coordinator, then the key should be left out of the result so that the request will be retried.
      Parameters:
      keys - the set of keys from the associated request
      response - the response received from the broker
      Returns:
      a result indicating which keys mapped successfully to a brokerId and which encountered a fatal error

    • handleUnsupportedVersionException

      default Map<T,Throwable> handleUnsupportedVersionException(org.apache.kafka.common.errors.UnsupportedVersionException exception, Set<T> keys)
      Callback that is invoked when a lookup request hits an UnsupportedVersionException. Keys for which the exception cannot be handled and the request shouldn't be retried must be mapped to an error and returned. The remainder of the keys will then be unmapped and the lookup request will be retried for them.
      Returns:
      The failure mappings for the keys for which the exception cannot be handled and the request shouldn't be retried. If the exception cannot be handled all initial keys will be in the returned map.