-
Notifications
You must be signed in to change notification settings - Fork 263
Application not starting when Kafka Servers down #53
Comments
This behaviour matches what |
Can we log the messages to console if brokers are not reachable? If primary is not available it will go to secondary (fail-over) broker and if both are not reachable then write it to console. |
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 messages might end up in the fallback appender. Would that be a valid behaviour for you? |
Yes Daniel, All we need is application should not be impacted if primary
and fallback brokers are down or unreachable.
…On Thu, Nov 23, 2017 at 5:26 PM, Daniel Wegener ***@***.***> wrote:
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* messages might end up in the
fallback appender. Would that be a valid behaviour for you?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#53 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/APsQ-bcGAIBr4dy9vhc_Zjk9RZgSghjxks5s5fEWgaJpZM4QKFTT>
.
|
+1 on this, also needed. |
@danielwegener please see #56 we believe the issue is that the lazy producer fails to initialise a producer, thus returns null on lazyproducer.get this is then passed to and then invoked within the delegating deliveryStrategy causing an NPE |
@michaelandrepearce Thanks for the PR. Your fix will still not fix the issue that the broker start may block the logging thread during metadata exchange (and since the start is synchronized possibly all other threads that start to log). But when the broker is not available at all (no route to host or other "fast" cancellations) - this fix can at least make sure that "some" logs arrive in the fallback appender. This is still a very unfortunate situation because the failed producer start will automatically be retried for every following logging attempt (and each time issue possibly expensive kafka-producer start attempts). |
@danielwegener agreed. Just NPE fix sorts as you say the most trivial and easiest to hit issue. |
+1 for the issue ran to this issue and impacted our current application availability, where we have fallback mechanism to write messages in case error to another file store, not sure how this is behaving with Rabbit MQ |
This issue is old but do we have resolution for it. |
java.lang.IllegalStateException: Logback configuration error detected: |
I'm using Spring boot and danielwegener kafka appender to publish application logs to Kafka but the spring boot application is not starting when Kafka server are down.
Can you please advise to resolve this issue?
The text was updated successfully, but these errors were encountered: