[
https://issues.apache.org/jira/browse/NIFI-8745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Taft updated NIFI-8745:
----------------------------
Description:
I have seen this NullPointerException several times recently. This is
apparently coming from the bootstrap component. But really unfortunately, the
stacktrace is being echoed to standard out/err and not captured in any log.
{{
java.lang.NullPointerException
at
org.apache.nifi.bootstrap.BootstrapCodec.communicate(BootstrapCodec.java:44)
at
org.apache.nifi.bootstrap.NiFiListener$Listener$2.run(NiFiListener.java:122)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
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)
}}
A fix on line 44 to prevent the NPE should be obvious, but the cause is
unknown. I speculate that the system being run on is scanned (probably a
malware / open port scanner) for compliance reasons. However, I honestly don't
know anything more at this point as to a direct cause.
There is an IOException that can potentially be thrown if the codec
communication is invalid (line 46). It would be good to check (after fixing the
NPE) whether the thrown exception would be logged to the bootstrap log or be
output to standard out, like the above stack trace is currently. Ideally, any
exception thrown by the bootstrap code should be caught and logged, not output
to the console.
It might be wise to consider this a non-error. An open port scanner (as
hypothesized above) should be able to run against the bootstrap listener
without causing a stack trace at all. Maybe just an "INFO" logging, that some
non-NiFi client connected. It's unlikely that a stacktrace adds much value to
the diagnosing of a random socket client. Maybe the INFO logging could include
remote IP and port of connecting client.
was:
I have seen this NullPointerException several times recently. This is
apparently coming from the bootstrap component. But really unfortunately, the
stacktrace is being echoed to standard out/err and not captured in any log.
{{
java.lang.NullPointerException
at
org.apache.nifi.bootstrap.BootstrapCodec.communicate(BootstrapCodec.java:44)
at
org.apache.nifi.bootstrap.NiFiListener$Listener$2.run(NiFiListener.java:122)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
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)
}}
A fix on line 44 to prevent the NPE should be obvious, but the cause is
unknown. I speculate that the system being run on is scanned (probably a
malware / open port scanner) for compliance reasons. However, I honestly don't
know anything more at this point as to a direct cause.
There is an IOException that can potentially be thrown if the codec
communication is invalid (line 46). It would be good to check whether the
thrown exception would be logged to the bootstrap log or be output to standard
out, like the above stack trace is currently. Ideally, any exception thrown by
the bootstrap code should be caught and logged, not output to the console.
It might be wise to consider this a non-error. An open port scanner (as
hypothesized above) should be able to run against the bootstrap listener
without causing a stack trace at all. Maybe just an "INFO" logging, that some
non-NiFi client connected. It's unlikely that a stacktrace adds much value to
the diagnosing of a random socket client. Maybe the INFO logging could include
remote IP and port of connecting client.
> NullPointerException in Bootstrap
> ---------------------------------
>
> Key: NIFI-8745
> URL: https://issues.apache.org/jira/browse/NIFI-8745
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
> Affects Versions: 1.13.2
> Environment: JDK 1.8 - Ubuntu Server
> Reporter: Adam Taft
> Priority: Major
>
> I have seen this NullPointerException several times recently. This is
> apparently coming from the bootstrap component. But really unfortunately, the
> stacktrace is being echoed to standard out/err and not captured in any log.
> {{
> java.lang.NullPointerException
> at
> org.apache.nifi.bootstrap.BootstrapCodec.communicate(BootstrapCodec.java:44)
> at
> org.apache.nifi.bootstrap.NiFiListener$Listener$2.run(NiFiListener.java:122)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 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)
> }}
> A fix on line 44 to prevent the NPE should be obvious, but the cause is
> unknown. I speculate that the system being run on is scanned (probably a
> malware / open port scanner) for compliance reasons. However, I honestly
> don't know anything more at this point as to a direct cause.
> There is an IOException that can potentially be thrown if the codec
> communication is invalid (line 46). It would be good to check (after fixing
> the NPE) whether the thrown exception would be logged to the bootstrap log or
> be output to standard out, like the above stack trace is currently. Ideally,
> any exception thrown by the bootstrap code should be caught and logged, not
> output to the console.
> It might be wise to consider this a non-error. An open port scanner (as
> hypothesized above) should be able to run against the bootstrap listener
> without causing a stack trace at all. Maybe just an "INFO" logging, that some
> non-NiFi client connected. It's unlikely that a stacktrace adds much value to
> the diagnosing of a random socket client. Maybe the INFO logging could
> include remote IP and port of connecting client.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
