You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on May 27, 2022. It is now read-only.
When the producer config is wrong, the createProducer raises an exception.
As this method is called by the LazyInitializer when a log arrives, each logs tries to create a producer, it fails and a stack trace is logged.
Prior to 0.2-RC1, the producer config check may have mitigated this issue.
Some solutions I can see:
Let the producer to be created when the KafkaAppender starts (eager initialization), this would bring a fail fast behaviour but may slow down startup.
Add some circuit breaker behaviour in the LazyInitializer, and allow only one producer creation.
The text was updated successfully, but these errors were encountered:
eager initialization: I am not sure if I remember correctly but the eager initialization is either really early (on the logger creation thread which may be the classloader thread which initializes private static Logger LOG fields) OR the first logging call (which again might be a user request thread).
But I agree, the config check should fail as soon as possible and only once. To fix this particular issue I'd however prefer the second option until we find a good abstraction for the producer lifecycle issues (see my comment on your PR).
I also see endless stacktrace with bad producer config. Is there a way to restrict the no of retrials to a particular number?
I tried the below config but has no affect on endless stacktrace:
reconnect.backoff.ms=4000
request.timeout.ms=4000
retry.backoff.ms=1000
I did add fallback appender.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
When the producer config is wrong, the createProducer raises an exception.
As this method is called by the LazyInitializer when a log arrives, each logs tries to create a producer, it fails and a stack trace is logged.
Prior to 0.2-RC1, the producer config check may have mitigated this issue.
Some solutions I can see:
The text was updated successfully, but these errors were encountered: