Daniel Wegener

Ouch, thats a bummer. The blocking on the lazy producer should only happen on application start, (can you confirm that this blocking behaviour only happens on application startup?). Regarding the...

Because kafka tries to recursively log to itself which may lead it into a deadlock (which forunately is eventually resolved by the metadata timeout, but still breaks your client). The...

@Birdflying1005 good point :)

Can you guys imagine some doc/faq-entry or something that would have helped you to not run into this issue? I'd be happy to add it to the documentation

Interesting :) and a bit surprising. Indeed, with that configuration the appender is not supposed to block anything. I'll try to reproduce that behavior in a test tomorrow, but a...

Oh yeah I see what you mean. Actually it does not really block the application completely but lets just one log message through (join the buffer) like every 60 seconds...

I currently have no good Idea how to handle that. I think we have to wait for kafka 0.9 (https://issues.apache.org/jira/browse/KAFKA-2120) to solve this in nice way.

I released logback-kafka-appender 0.0.5 with kafka 0.9.0 today. Maybe you can try fiddling with the `request.timeout.ms` setting [described here](http://kafka.apache.org/documentation.html#producerconfigs).

This behaviour matches what `ch.qos.logback.classic.net.SocketAppender` would do (except an additional buffer). What would you expect to happen if the broker is unreachable? Where should the unlogged messages go (dropped/delegated to...

Yeah, thats what fallback-appenders are meant to be for (see the Readme). But still - the Producer will not _instantly_ be ready when the application starts, so the first _n_...