Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Plain View
Kafka >> mail # user >> Stale TopicMetadata


Copy link to this message
-
Stale TopicMetadata
Hi there. Once again, I don't think I could get the docs on another topic.

So my nodejs client connects to the broker and the first thing it does is
store the topic metadata:

data received
{
    "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
}

Ok, so far so good. So I kill node 0 on purpose. Trying to simulate a
broker failure, and then I fetch metadata again:

data received
{
    "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
}

Well, I can see from partition metadata that some partions have no leader
(-1), but my problem is that I actually rely on the brokers list to create
a pool of connections. And even when the broker 0 is down, I still get it
back from the metadata. Is this what is expected? I know it could be that
brokers are only a list of all places where that topic could be found, but
in that case couldn't we at least have a flag indicating wether that broker
is online or not?

Regards

The intuitive mind is a sacred gift and the
rational mind is a faithful servant. We have
created a society that honors the servant and
has forgotten the gift.

 
+
Jun Rao 2013-07-11, 05:16
+
Vinicius Carvalho 2013-07-11, 13:35
+
Colin Blower 2013-07-11, 17:54
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB