Kafka
  1. Kafka
  2. KAFKA-972

MetadataRequest returns stale list of brokers

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 0.8.0
    • Fix Version/s: None
    • Component/s: core
    • Labels:
      None

      Description

      When we issue an metadatarequest towards the cluster, the list of brokers is stale. I mean, even when a broker is down, it's returned back to the client. The following are examples of two invocations one with both brokers online and the second with a broker down:

      {
      "brokers": [

      { "nodeId": 0, "host": "10.139.245.106", "port": 9092, "byteLength": 24 }

      ,

      { "nodeId": 1, "host": "localhost", "port": 9093, "byteLength": 19 }

      ],
      "topicMetadata": [
      {
      "topicErrorCode": 0,
      "topicName": "foozbar",
      "partitions": [

      { "replicas": [ 0 ], "isr": [ 0 ], "partitionErrorCode": 0, "partitionId": 0, "leader": 0, "byteLength": 26 }

      ,

      { "replicas": [ 1 ], "isr": [ 1 ], "partitionErrorCode": 0, "partitionId": 1, "leader": 1, "byteLength": 26 }

      ,

      { "replicas": [ 0 ], "isr": [ 0 ], "partitionErrorCode": 0, "partitionId": 2, "leader": 0, "byteLength": 26 }

      ,

      { "replicas": [ 1 ], "isr": [ 1 ], "partitionErrorCode": 0, "partitionId": 3, "leader": 1, "byteLength": 26 }

      ,

      { "replicas": [ 0 ], "isr": [ 0 ], "partitionErrorCode": 0, "partitionId": 4, "leader": 0, "byteLength": 26 }

      ],
      "byteLength": 145
      }
      ],
      "responseSize": 200,
      "correlationId": -1000
      }

      {
      "brokers": [

      { "nodeId": 0, "host": "10.139.245.106", "port": 9092, "byteLength": 24 }

      ,

      { "nodeId": 1, "host": "localhost", "port": 9093, "byteLength": 19 }

      ],
      "topicMetadata": [
      {
      "topicErrorCode": 0,
      "topicName": "foozbar",
      "partitions": [

      { "replicas": [ 0 ], "isr": [], "partitionErrorCode": 5, "partitionId": 0, "leader": -1, "byteLength": 22 }

      ,

      { "replicas": [ 1 ], "isr": [ 1 ], "partitionErrorCode": 0, "partitionId": 1, "leader": 1, "byteLength": 26 }

      ,

      { "replicas": [ 0 ], "isr": [], "partitionErrorCode": 5, "partitionId": 2, "leader": -1, "byteLength": 22 }

      ,

      { "replicas": [ 1 ], "isr": [ 1 ], "partitionErrorCode": 0, "partitionId": 3, "leader": 1, "byteLength": 26 }

      ,

      { "replicas": [ 0 ], "isr": [], "partitionErrorCode": 5, "partitionId": 4, "leader": -1, "byteLength": 22 }

      ],
      "byteLength": 133
      }
      ],
      "responseSize": 188,
      "correlationId": -1000
      }

        Issue Links

          Activity

          Hide
          Jun Rao added a comment -

          Could you describe how to reproduce this?

          Show
          Jun Rao added a comment - Could you describe how to reproduce this?
          Hide
          Neha Narkhede added a comment -

          Is this repetitive or the metadata starts returning consistent data after some time ? Since the metadata is communicated to the brokers by the controller, it is possible that there is a time window after an event has happened and before all the brokers have learned of the event.

          Show
          Neha Narkhede added a comment - Is this repetitive or the metadata starts returning consistent data after some time ? Since the metadata is communicated to the brokers by the controller, it is possible that there is a time window after an event has happened and before all the brokers have learned of the event.

            People

            • Assignee:
              Unassigned
              Reporter:
              Vinicius Carvalho
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:

                Development