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

Class AllBrokersStrategy

java.lang.Object
org.apache.kafka.clients.admin.internals.AllBrokersStrategy
All Implemented Interfaces:
AdminApiLookupStrategy<AllBrokersStrategy.BrokerKey>
public class AllBrokersStrategy extends Object implements AdminApiLookupStrategy<AllBrokersStrategy.BrokerKey>
This class is used for use cases which require requests to be sent to all brokers in the cluster. This is a slightly degenerate case of a lookup strategy in the sense that the broker IDs are used as both the keys and values. Also, unlike CoordinatorStrategy and PartitionLeaderStrategy, we do not know the set of keys ahead of time: we require the initial lookup in order to discover what the broker IDs are. This is represented with a more complex type Future<Map<Integer, Future<V>> in the admin API result type. For example, see ListTransactionsResult.

  • Field Details

  • Constructor Details

    • AllBrokersStrategy

      public AllBrokersStrategy(org.apache.kafka.common.utils.LogContext logContext)

  • Method Details

    • lookupScope

      public ApiRequestScope lookupScope(AllBrokersStrategy.BrokerKey key)
      Description copied from interface: AdminApiLookupStrategy
      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.
      Specified by:
      lookupScope in interface AdminApiLookupStrategy<AllBrokersStrategy.BrokerKey>
      Parameters:
      key - the lookup key
      Returns:
      request scope indicating how lookup requests can be batched together

    • buildRequest

      public org.apache.kafka.common.requests.MetadataRequest.Builder buildRequest(Set<AllBrokersStrategy.BrokerKey> keys)
      Description copied from interface: AdminApiLookupStrategy
      Build the lookup request for a set of keys. The grouping of the keys is controlled through AdminApiLookupStrategy.lookupScope(Object). In other words, each set of keys that map to the same request scope object will be sent to this method.
      Specified by:
      buildRequest in interface AdminApiLookupStrategy<AllBrokersStrategy.BrokerKey>
      Parameters:
      keys - the set of keys that require lookup
      Returns:
      a builder for the lookup request

    • handleResponse

      public AdminApiLookupStrategy.LookupResult<AllBrokersStrategy.BrokerKey> handleResponse(Set<AllBrokersStrategy.BrokerKey> keys, org.apache.kafka.common.requests.AbstractResponse abstractResponse)
      Description copied from interface: AdminApiLookupStrategy
      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.
      Specified by:
      handleResponse in interface AdminApiLookupStrategy<AllBrokersStrategy.BrokerKey>
      Parameters:
      keys - the set of keys from the associated request
      abstractResponse - the response received from the broker
      Returns:
      a result indicating which keys mapped successfully to a brokerId and which encountered a fatal error