Appreciate you looking into this. > Is the error occurring when the processor starts?
No, usually comes at random times when it is running. Presumably when "something" happens with the network or the connection against Splunk? > If that's when a flow file is being processed, is there anything special > about this flow file (like no content at all)? Not as far as I have been able to identify. I've run the same data in parallell and it might fail in one pipeline and not the other. With the same data. As far as I can tell, when I restart the failing PutSplunk processors, it'll reprocess the failed flowfiles, and they tend to work just fine with no problems next time around. We have a number of PutSplunk processors. Some are getting these NPEs, while others are not. While not conclusive, the PutSplunk processors that seem to throw NPEs appears to be the more busy ones. But that might just be that they have more chances to fail due to more flowfiles and data being processed. In our lab environment, I've kinda managed to sometimes get the same error (if "lucky") when doing a rolling restart of the Splunk cluster while PutSplunk is running. So that might be a way to reproduce it, but not consistently. The connection against the Splunk indexers is through a loadbalancer, so that adds an extra component that could do something with the connection. Regards, Anders On Tue, Jan 19, 2021 at 8:36 AM Pierre Villard <[email protected]> wrote: > 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 >>>> >>>>
