kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Arthur <mum...@gmail.com>
Subject Re: Log4jAppender backoff if server is down
Date Wed, 01 Aug 2012 00:08:22 GMT
Here are some log snippets:

Kafka server logs: https://gist.github.com/c440ada8daa629e337e2
Solr logs: https://gist.github.com/42624c901fc7967fd137

In this case, I am sending all the "org.apache.solr" logs to Kafka, so each document update
in Solr produces a log message. Each update to Solr produced an exception like this which
caused things to slow way down.

My earlier statement about Kafka being up but unable to write logs was incorrect. During this,
it seems Kafka was simply down (our supervisor that restarts Kafka gave up after a few tries).
So in the case that Kafka is down, what should the client behavior be like?

Ideally, to me, the client could know about what brokers are available through ZK watches
and just refuse to attempt a send/produce if no one is available.

What do you guys think? I'm not saying this is necessarily a Kafka issue, I'm just not sure
what's the best thing to do here.


On Jul 31, 2012, at 5:48 PM, Neha Narkhede wrote:

> David,
> Would you mind sending around the error stack traces ? That will help
> determine the right fix.
> Thanks,
> Neha
> On Tue, Jul 31, 2012 at 1:09 PM, David Arthur <mumrah@gmail.com> wrote:
>> Greetings all,
>> I'm using the KafkaLog4jAppender with Solr and ran into an interesting issue recently.
The disk filled up on my Kafka broker (just a single broker, this is a dev environment) and
Solr slowed down to a near halt. My best estimation is that each log4j log message created
was incurring quite a bit of overhead dealing with exceptions coming back from the Kafka broker.
>> So I'm wondering, would it make sense to implement some back off strategy for this
client if it starts getting exceptions from the server? Alternatively, could maybe the Kafka
broker mark it self as "down" in ZooKeeper if it gets into certain situations (like disk full).
I guess this really could apply to any client, not just the log4j appender.
>> Thanks!
>> -David

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message