Thanks for the quick response. Conrad From: Mark Payne <[email protected]<mailto:[email protected]>> Reply-To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Date: Wednesday, 16 March 2016 at 15:18 To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: NPE in ExtractText
Conrad, I have never seen this personally. However, given your description, I was able to create a unit test that replicates the issue. I created a JIRA for this [1]. It was easily replicated. We should have a fix available for the 0.6.0 release. Thanks! -Mark [1] https://issues.apache.org/jira/browse/NIFI-1632 On Mar 16, 2016, at 11:08 AM, Conrad Crampton <[email protected]<mailto:[email protected]>> wrote: Hi, I don’t know if this is expected behaviour but I think I understand why this is happening now. I have a regexp in the ExtractText processors viz: (?s:^.+: (\d\d?)(\w\w\w)(\d{4}) ([\d ]\d:\d\d:\d\d) Product=(.+?) OriginIP=(.+?) Origin=(.+?) Action=(.+?) SIP=(.+?) Source=(.+?) SPort=(\d+?) DIP=(.+) Destination=(.+?) DPort=(\d+?) Protocol=(.+?)(?: ICMPType=(.+?) ICMPCode=(.+?))? IFName=(.+?) IFDirection=(.+?) Reason=(.+?) Rule=(.+?) PolicyName=(.+?) Info=(.+?) XlateSIP=(.+?) XlateSPort=([\d]+|\-?) XlateDIP=(.+?) XlateDPort=([\d]+|\-?)(.*)$) With this (?: ICMPType=(.+?) ICMPCode=(.+?))? the problem I think. Because I have made a non capturing matching group optional, for those log lines that don’t have this section matching the dynamic variable can’t set the index correctly as the match is returning null for these capture groups. Obviously I haven’t gone too deep into the code, but if I have a RouteOnContent processor before this testing for this string and remove this from regexp (and have two ExtractText processors) then it works. It appeared that all the NPE were thrown for those lines that didn’t match the optional matching group. Has this been observed before? Thanks Conrad From: Conrad Crampton <[email protected]<mailto:[email protected]>> Reply-To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Date: Wednesday, 16 March 2016 at 12:01 To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: NPE in ExtractText Hi, I’m getting repeated NullPointerException reported for an ExtractText processor (processing the resultant splits from a ListenSyslog) thus: datanode2-cm1.mis-cds.local:9092ExtractText[id=4372efbf-efcf-3065-acd4-b8fdb91d64fb] ExtractText[id=4372efbf-efcf-3065-acd4-b8fdb91d64fb] failed to process due to java.lang.NullPointerException; rolling back session: java.lang.NullPointerException The same error appears for each node in my cluster too so not specific to one node. I have enabled additional logging for ExtractText processor (I think) by adding <logger name="org.apache.nifi.processors.standard.ExtractText" level=“DEBUG" additivity="false"> <appender-ref ref="USER_FILE"/> </logger> To each logback.xml on each node, but this doesn’t give any more details as to why the NPE. Flowflies are getting through the processor but concerned about the errors as clearly something isn’t correct so suggestions welcome. Thanks Conrad SecureData, combating cyber threats ________________________________ The information contained in this message or any of its attachments may be privileged and confidential and intended for the exclusive use of the intended recipient. If you are not the intended recipient any disclosure, reproduction, distribution or other dissemination or use of this communications is strictly prohibited. The views expressed in this email are those of the individual and not necessarily of SecureData Europe Ltd. Any prices quoted are only valid if followed up by a formal written quote. SecureData Europe Limited. Registered in England & Wales 04365896. Registered Address: SecureData House, Hermitage Court, Hermitage Lane, Maidstone, Kent, ME16 9NT ***This email originated outside SecureData*** Click here<https://www.mailcontrol.com/sr/MZbqvYs5QwJvpeaetUwhCQ==> to report this email as spam.
