[
https://issues.apache.org/jira/browse/NIFI-7035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17129295#comment-17129295
]
Makarov Vasiliy Nicolaevich edited comment on NIFI-7035 at 6/9/20, 1:57 PM:
----------------------------------------------------------------------------
[~Absolutesantaja] [~rabikumar.kc]
Ok, so I have reproduced the issue. It occurs when NiFi is in cluster mode but
has no access to one of the Zookeper nodes (embedded in my case).
I will try to limit it / filter excessive logs out it on Logbase config part
because as I see we don't explicitly log this error in NiFi code.
Also, this task is related it seems to:
[https://issues.apache.org/jira/browse/NIFI-3731]
[~randgalt] indicated there that Curator has a switch to log only the first
error as an ERROR level and others as DEBUG level. Don't know if it helps in
the situation with zookeeper only.
Any advice would be appreciated though.
was (Author: feitgraph):
[~Absolutesantaja] [~rabikumar.kc]
Ok, so I have reproduced the issue. It occurs when NiFi is in cluster mode but
has no access to one of the Zookeper nodes (embedded in my case).
I will try to limit it / filter excessive logs out it on Logbase config part
because as I see we don't explicitly log this error in NiFi code.
Also, this task is related it seems to:
[https://issues.apache.org/jira/browse/NIFI-3731
] [~randgalt] indicated there that Curator has a switch to log only the first
error as an ERROR level and others as DEBUG level. Don't know if it helps in
the situation with zookeeper only.
Any advice would be appreciated though.
> Don't spam logs with Apache Curator errors on Zookeeper Disconnect
> ------------------------------------------------------------------
>
> Key: NIFI-7035
> URL: https://issues.apache.org/jira/browse/NIFI-7035
> Project: Apache NiFi
> Issue Type: Improvement
> Reporter: Shawn Weeks
> Assignee: Makarov Vasiliy Nicolaevich
> Priority: Trivial
>
> Sometimes when you startup NiFi and not all of the Zookeeper nodes aren't up
> it fills the logs with Apache Curator errors like this one. We should be able
> to improve this a bit as logging the same error repeatedly isn't helpful.
> {code:java}
> 2020-01-16 08:58:28,767 ERROR [Curator-Framework-0]
> o.a.c.f.imps.CuratorFrameworkImpl Background retry gave up
> org.apache.curator.CuratorConnectionLossException: KeeperErrorCode =
> ConnectionLoss
> at
> org.apache.curator.framework.imps.CuratorFrameworkImpl.performBackgroundOperation(CuratorFrameworkImpl.java:972)
> at
> org.apache.curator.framework.imps.CuratorFrameworkImpl.backgroundOperationsLoop(CuratorFrameworkImpl.java:943)
> at
> org.apache.curator.framework.imps.CuratorFrameworkImpl.access$300(CuratorFrameworkImpl.java:66)
> at
> org.apache.curator.framework.imps.CuratorFrameworkImpl$4.call(CuratorFrameworkImpl.java:346)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
