[
https://issues.apache.org/jira/browse/NIFI-3738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15983471#comment-15983471
]
ASF GitHub Bot commented on NIFI-3738:
--------------------------------------
GitHub user alopresto opened a pull request:
https://github.com/apache/nifi/pull/1694
NIFI-3738 Fixed NPE when ListenSyslog UDP datagram has zero length.
Added default constructor to SyslogParser to allow map coercion for test.
Added unit test.
Thank you for submitting a contribution to Apache NiFi.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
### For all changes:
- [x] Is there a JIRA ticket associated with this PR? Is it referenced
in the commit message?
- [x] Does your PR title start with NIFI-XXXX where XXXX is the JIRA number
you are trying to resolve? Pay particular attention to the hyphen "-" character.
- [x] Has your PR been rebased against the latest commit within the target
branch (typically master)?
- [x] Is your initial contribution a single, squashed commit?
### For code changes:
- [x] Have you ensured that the full suite of tests is executed via mvn
-Pcontrib-check clean install at the root nifi folder?
- [x] Have you written or updated unit tests to verify your changes?
- [ ] If adding new dependencies to the code, are these dependencies
licensed in a way that is compatible for inclusion under [ASF
2.0](http://www.apache.org/legal/resolved.html#category-a)?
- [ ] If applicable, have you updated the LICENSE file, including the main
LICENSE file under nifi-assembly?
- [ ] If applicable, have you updated the NOTICE file, including the main
NOTICE file found under nifi-assembly?
- [ ] If adding new Properties, have you added .displayName in addition to
.name (programmatic access) for each of the new properties?
### For documentation related changes:
- [ ] Have you ensured that format looks appropriate for the output in
which it is rendered?
### Note:
Please ensure that once the PR is submitted, you check travis-ci for build
issues and submit an update to your PR as soon as possible.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/alopresto/nifi NIFI-3738
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/nifi/pull/1694.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #1694
----
commit 81d33388d27ac2100972e01a4724f09c539bd5f3
Author: Andy LoPresto <[email protected]>
Date: 2017-04-25T19:10:16Z
NIFI-3738 Fixed NPE when ListenSyslog UDP datagram has zero length.
Added default constructor to SyslogParser to allow map coercion for test.
Added unit test.
----
> NPE in ListenSyslog processor when datagram size is zero
> --------------------------------------------------------
>
> Key: NIFI-3738
> URL: https://issues.apache.org/jira/browse/NIFI-3738
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
> Affects Versions: 1.1.1
> Environment: java version Oracle 1.8.0_51
> linux 2.6.32-573.7.1.el6.x86_64
> Reporter: Conrad Crampton
> Assignee: Andy LoPresto
> Priority: Minor
>
> I have a 6 node cluster with an F5 load balancer in front to distribute UDP
> syslog load. It splits an incoming syslog stream and sends separate lines to
> each node in the cluster (I am checking if zero length datagrams are being
> sent from the F5 LB). However, from Bryan Bende from user mailing lists
> >>>
> Line 431 of ListenSyslog has the following code:
> if (!valid || !event.isValid())
> So to get an NPE there means event must be null, and event comes from this
> code:
> boolean valid = true;
> try {
> event = parser.parseEvent(rawSyslogEvent.getData(), sender);
> } catch (final ProcessException pe) {
> getLogger().warn("Failed to parse Syslog event; routing to invalid");
> valid = false;
> }
> The parser returns null if the bytes sent in are null or length 0.
> We should be checking if (!valid || event == null || !event.isValid())
> to avoid this case, and I think a similar situation exists in the
> ParseSyslog processor. It appears this would only happen if parsing
> messages is enabled in ListenSyslog.
> <<<<
> and log file snippet is
> 2017-04-25 17:43:07,549 ERROR [Timer-Driven Process Thread-2]
> o.a.n.processors.standard.ListenSyslog
> ListenSyslog[id=0a932c37-0158-1000-0000-0000656754bf]
> ListenSyslog[id=0a932c37-0158-1000-0000-0000656754bf] failed to process
> session due to java.lang.NullPointerException: java.lang.NullPointerException
> 2017-04-25 17:43:07,550 ERROR [Timer-Driven Process Thread-2]
> o.a.n.processors.standard.ListenSyslog
> java.lang.NullPointerException: null
> at
> org.apache.nifi.processors.standard.ListenSyslog.onTrigger(ListenSyslog.java:431)
> ~[na:na]
> at
> org.apache.nifi.processor.AbstractProcessor.onTrigger(AbstractProcessor.java:27)
> ~[nifi-api-1.1.2.jar:1.1.2]
> at
> org.apache.nifi.controller.StandardProcessorNode.onTrigger(StandardProcessorNode.java:1099)
> ~[nifi-framework-core-1.1.2.jar:1.1.2]
> at
> org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:136)
> [nifi-framework-core-1.1.2.jar:1.1.2]
> at
> org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:47)
> [nifi-framework-core-1.1.2.jar:1.1.2]
> at
> org.apache.nifi.controller.scheduling.TimerDrivenSchedulingAgent$1.run(TimerDrivenSchedulingAgent.java:132)
> [nifi-framework-core-1.1.2.jar:1.1.2]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [na:1.8.0_51]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> [na:1.8.0_51]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> [na:1.8.0_51]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> [na:1.8.0_51]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [na:1.8.0_51]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [na:1.8.0_51]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_51]
> 2017-04-25 17:43:07,550 WARN [Timer-Driven Process Thread-2]
> o.a.n.processors.standard.ListenSyslog
> ListenSyslog[id=0a932c37-0158-1000-0000-0000656754bf] Processor
> Administratively Yielded for 1 sec due to processing failure
> 2017-04-25 17:43:07,550 WARN [Timer-Driven Process Thread-2]
> o.a.n.c.t.ContinuallyRunProcessorTask Administratively Yielding
> ListenSyslog[id=0a932c37-0158-1000-0000-0000656754bf] due to uncaught
> Exception: java.lang.NullPointerException
> 2017-04-25 17:43:07,551 WARN [Timer-Driven Process Thread-2]
> o.a.n.c.t.ContinuallyRunProcessorTask
> java.lang.NullPointerException: null
> at
> org.apache.nifi.processors.standard.ListenSyslog.onTrigger(ListenSyslog.java:431)
> ~[na:na]
> at
> org.apache.nifi.processor.AbstractProcessor.onTrigger(AbstractProcessor.java:27)
> ~[nifi-api-1.1.2.jar:1.1.2]
> at
> org.apache.nifi.controller.StandardProcessorNode.onTrigger(StandardProcessorNode.java:1099)
> ~[nifi-framework-core-1.1.2.jar:1.1.2]
> at
> org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:136)
> [nifi-framework-core-1.1.2.jar:1.1.2]
> at
> org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:47)
> [nifi-framework-core-1.1.2.jar:1.1.2]
> at
> org.apache.nifi.controller.scheduling.TimerDrivenSchedulingAgent$1.run(TimerDrivenSchedulingAgent.java:132)
> [nifi-framework-core-1.1.2.jar:1.1.2]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [na:1.8.0_51]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> [na:1.8.0_51]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> [na:1.8.0_51]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> [na:1.8.0_51]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [na:1.8.0_51]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [na:1.8.0_51]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_51]
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
