How to suppress librdkafka log-messages completely and efficient ?

[Carrrot]

Description

Hello,

i got some questions about suppressing log messages caused by librdkafka, please follow along the events:

Like in @confluentinc/librdkafka#437 i see log messages from underlying librdkafka:

1507111970.888|ERROR|rdkafka#consumer-11| <some_IP>:9092/49: Receive failed: Disconnected

which i successfully suppress by using 'log.connection.close': 'false'. Shortly after the above occures i see messages like these in my logs:

1507111970.888|ERROR|rdkafka#consumer-11| 4/4 brokers are down

As far as i understood this is a logical consequence. Since the producer is out of messages, let´s say "drained" it will loosely disconnect the consumers and notice them if there are new messages to consume.

Since the message is not important to me, i tried to suppress them like @confluentinc/librdkafka#915 suggests by setting topic.metadata.refresh.interval.ms to an interval lower than connection.max.idle.ms. Which i suppose (i do not have access to the Kafka instance nor configs) is about 300000 ms .

This only does the job half-way because these messages still pop up every now and then. Also i wonder if this is the best way to solve the problem. Like @confluentinc/librdkafka#437 (comment) states, heartbeating is a costly thing.

Is there a better way to handle this behaviour which suppresses the messages and also is not that costly ?

How to reproduce

N/A

Checklist

Please provide the following information:

• confluent-kafka-python and librdkafka version (('0.11.0', 720896) and ('0.11.0', 721151)):
• Apache Kafka broker version: 0.9
• Client configuration: {'session.timeout.ms': 6000, 'log.connection.close': 'false', 'api.version.request': 'false', 'broker.version.fallback':'0.9.0.1', 'topic.metadata.refresh.interval.ms': 270000, 'default.topic.config': {'auto.offset.reset': 'smallest', 'enable.auto.commit': 'true', 'offset.store.method': 'broker'}}
• Operating system: Linux
• Provide client logs (with 'debug': '..' as necessary)
• Provide broker log excerpts: N/A
• Critical issue

[rjurney]

+1

[edenhill]

Sorry for the long delay:

With regards to "..all brokers are down", I think that is actually an issue that has been fixed in librdkafka: 0.11.3:
confluentinc/librdkafka#1101

With that fix in place and log.connection.close: False you should be good, right?

There is currently no reliable way to avoid the idle connection reaper to kick in since even if you set a low metadata refresh interval the client will only use a random connection each interval, not all.

[edenhill]

Dup #148