Not sure what is the best approach here... Having a NPE without a stacktrace is definitely something we should improve on our side even if the root cause is external. I did look at the code very quickly and didn't see anything obvious.
Is the error occurring when the processor starts? If that's when a flow file is being processed, is there anything special about this flow file (like no content at all)? Thanks, Pierre Le ven. 15 janv. 2021 à 16:37, Anders Synstad <[email protected]> a écrit : > Thank you for the reply Pierre, > > I'm afraid there isn't a stack trace to post. While there are stack traces > logged for other problems, the 2 loglines I've posted is all that is > logged > whenever this occurs. > > Enabling full debug logging on the installation in question is > unfortunately > not feasible. > > Found NIFI-4610 which appears to describe a similar problem but with a > different processor (ExtractHL7Attributes). Might not be related, or maybe > it's copy & pasted code with same bug or some libs being used with a > problem? Just throwing out random ideas. > > > Regards, > Anders > > On Fri, Jan 15, 2021 at 11:38 AM Pierre Villard < > [email protected]> wrote: > >> Hi Anders, >> >> Do you have a full stacktrace to share (probably available in >> nifi-app.log file)? >> It sounds like somethings that could be easily fixed. >> >> Thanks, >> Pierre >> >> Le ven. 15 janv. 2021 à 14:03, Anders Synstad <[email protected]> a >> écrit : >> >>> Hi. >>> >>> Anyone experienced NullPointerExceptions in PutSplunk? The only thing >>> logged is >>> the following: >>> >>> 2020-11-11 12:04:06,340 ERROR [Timer-Driven Process Thread-60] >>> o.a.nifi.processors.splunk.PutSplunk PutSplunk[id=<uuid>] >>> PutSplunk[id=<uuid>] failed to process session due to >>> java.lang.NullPointerException; Processor Administratively Yielded for 1 >>> sec: java.lang.NullPointerException >>> java.lang.NullPointerException: null >>> >>> The root cause of the NPE is probably something external to NiFi and >>> isn't the >>> main problem. The problem is that the flowfile isn't finalized >>> correctly, so >>> it's not sent to the failure relationship. It's just stuck in the >>> incoming >>> connection until the processor gets restarted and starts processing the >>> incoming connection from the start again, so the incoming connection >>> slowly >>> builds up with these until it's full. We've experienced the problem on >>> NiFi >>> versions from 1.7 (probably earlier) all the way up to latest 1.12.1. >>> >>> Is this a bug in PutSplunk not correctly handling this exception? Not >>> fluent >>> in java, but guessing maybe this happens around line 207 in the >>> PutSplunk code? >>> >>> >>> https://github.com/apache/nifi/blob/aa741cc5967f62c3c38c2a47e712b7faa6fe19ff/nifi-nar-bundles/nifi-splunk-bundle/nifi-splunk-processors/src/main/java/org/apache/nifi/processors/splunk/PutSplunk.java#L207 >>> >>> Any tips or hints would be greatly appreciated. >>> >>> >>> Regards, >>> Anders >>> >>>
