[jira] [Commented] (NIFI-10818) MergeContent 1.17.0 Bin no longer "make room for the new one" as documented
[ https://issues.apache.org/jira/browse/NIFI-10818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17635387#comment-17635387 ] Noe commented on NIFI-10818: no worries. Thank you for the quick fix, I will just update my 1.17 clusters with this code. > MergeContent 1.17.0 Bin no longer "make room for the new one" as documented > --- > > Key: NIFI-10818 > URL: https://issues.apache.org/jira/browse/NIFI-10818 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 1.17.0 >Reporter: Noe >Assignee: Mark Payne >Priority: Critical > Fix For: 1.19.0 > > Attachments: MergeContent_Bug.xml > > Time Spent: 0.5h > Remaining Estimate: 0h > > MergeContent bin no longer "make room for the new one" This feature works in > 1.15.2, but does not work in 1.17.0 > The bug is demostrated in the attached template. The queue before > MergeContent will back up do to new bins not being created for correlation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-10818) MergeContent 1.17.0 Bin no longer "make room for the new one" as documented
[ https://issues.apache.org/jira/browse/NIFI-10818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17635090#comment-17635090 ] Noe commented on NIFI-10818: Will this fix be available in 1.17.x? > MergeContent 1.17.0 Bin no longer "make room for the new one" as documented > --- > > Key: NIFI-10818 > URL: https://issues.apache.org/jira/browse/NIFI-10818 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 1.17.0 >Reporter: Noe >Assignee: Mark Payne >Priority: Critical > Fix For: 1.19.0 > > Attachments: MergeContent_Bug.xml > > Time Spent: 0.5h > Remaining Estimate: 0h > > MergeContent bin no longer "make room for the new one" This feature works in > 1.15.2, but does not work in 1.17.0 > The bug is demostrated in the attached template. The queue before > MergeContent will back up do to new bins not being created for correlation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-10818) MergeContent 1.17.0 Bin no longer "make room for the new one" as documented
Noe created NIFI-10818: -- Summary: MergeContent 1.17.0 Bin no longer "make room for the new one" as documented Key: NIFI-10818 URL: https://issues.apache.org/jira/browse/NIFI-10818 Project: Apache NiFi Issue Type: Bug Affects Versions: 1.17.0 Reporter: Noe Attachments: MergeContent_Bug.xml MergeContent bin no longer "make room for the new one" This feature works in 1.15.2, but does not work in 1.17.0 The bug is demostrated in the attached template. The queue before MergeContent will back up do to new bins not being created for correlation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (NIFI-7786) Bring back Trusted Hostname property from InvokeHTTP processor
[ https://issues.apache.org/jira/browse/NIFI-7786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17250884#comment-17250884 ] Noe edited comment on NIFI-7786 at 12/17/20, 2:08 PM: -- I have run into this issue and would like to see this option put back. As Nifi is used in various POCs it is advantageous to allow flexibility. "it can be imported into the local truststore explicitly" This is not the case. I ran into this problem after importing a Splunk default cert into the java/cacerts trustore that a Splunk server is using in development. A POC is not a reasonable time to harden an environment with standard security concerns. Can we please find a way to allow this functionality? Little irony, GetSplunk works against the same server but trying to make a dynamic query on Splunk utilizing rest with InvokeHttp jokes on cert validation. was (Author: ndet...@minerkasch.com): I have run into this issue and would like to see this option put back. As Nifi is used in various POCs it is advantageous to allow flexibility. "it can be imported into the local truststore explicitly" This is not the case. I ran into this problem after importing a Splunk default cert into the java/cacerts trustore that a Splunk server is using in development. A POC is not a reasonable time to harden an environment with standard security concerns. Can we please find a way to allow this functionality? > Bring back Trusted Hostname property from InvokeHTTP processor > -- > > Key: NIFI-7786 > URL: https://issues.apache.org/jira/browse/NIFI-7786 > Project: Apache NiFi > Issue Type: Bug >Reporter: Kun Deng >Priority: Major > > Removing this option is a mistake. Just google how many people need this > option for various reasons. > It is an option so that by using it, people are willing to take the risks. > > Please bring back this option. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (NIFI-7786) Bring back Trusted Hostname property from InvokeHTTP processor
[ https://issues.apache.org/jira/browse/NIFI-7786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17250884#comment-17250884 ] Noe commented on NIFI-7786: --- I have run into this issue and would like to see this option put back. As Nifi is used in various POCs it is advantageous to allow flexibility. "it can be imported into the local truststore explicitly" This is not the case. I ran into this problem after importing a Splunk default cert into the java/cacerts trustore that a Splunk server is using in development. A POC is not a reasonable time to harden an environment with standard security concerns. Can we please find a way to allow this functionality? > Bring back Trusted Hostname property from InvokeHTTP processor > -- > > Key: NIFI-7786 > URL: https://issues.apache.org/jira/browse/NIFI-7786 > Project: Apache NiFi > Issue Type: Bug >Reporter: Kun Deng >Priority: Major > > Removing this option is a mistake. Just google how many people need this > option for various reasons. > It is an option so that by using it, people are willing to take the risks. > > Please bring back this option. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (NIFI-7506) CompressContent Add Snappy-Hadoop
[ https://issues.apache.org/jira/browse/NIFI-7506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noe updated NIFI-7506: -- Description: I have been using this recommendation for a few months now and want to contribute it back Bryan Bende Nov 26, 2019, 12:54 PM to users Not sure if this is relevant, but snappy-java has a specific SnappyHadoopCompatibleOutputStream so CompressContent could offer a third snappy option like "snappy-hadoop" which used that. was: I have been using this recommendation for a few months now and want to contribute is back Bryan Bende Nov 26, 2019, 12:54 PM to users Not sure if this is relevant, but snappy-java has a specific SnappyHadoopCompatibleOutputStream so CompressContent could offer a third snappy option like "snappy-hadoop" which used that. > CompressContent Add Snappy-Hadoop > - > > Key: NIFI-7506 > URL: https://issues.apache.org/jira/browse/NIFI-7506 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Noe >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > I have been using this recommendation for a few months now and want to > contribute it back > Bryan Bende > Nov 26, 2019, 12:54 PM > to users > Not sure if this is relevant, but snappy-java has a specific > SnappyHadoopCompatibleOutputStream so CompressContent could offer a > third snappy option like "snappy-hadoop" which used that. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (NIFI-7506) CompressContent Add Snappy-Hadoop
[ https://issues.apache.org/jira/browse/NIFI-7506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17128694#comment-17128694 ] Noe commented on NIFI-7506: --- created pull request [https://github.com/apache/nifi/pull/4321] > CompressContent Add Snappy-Hadoop > - > > Key: NIFI-7506 > URL: https://issues.apache.org/jira/browse/NIFI-7506 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Noe >Priority: Major > > I have been using this recommendation for a few months now and want to > contribute is back > Bryan Bende > Nov 26, 2019, 12:54 PM > to users > Not sure if this is relevant, but snappy-java has a specific > SnappyHadoopCompatibleOutputStream so CompressContent could offer a > third snappy option like "snappy-hadoop" which used that. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (NIFI-4911) NiFi CompressContent Snappy incompatible behavior with Spark
[ https://issues.apache.org/jira/browse/NIFI-4911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17126195#comment-17126195 ] Noe commented on NIFI-4911: --- nifi-7506 will solve this > NiFi CompressContent Snappy incompatible behavior with Spark > > > Key: NIFI-4911 > URL: https://issues.apache.org/jira/browse/NIFI-4911 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 1.2.0 > Environment: HDF 3.0.2 running on Centos >Reporter: Nabeel Sarwar >Priority: Major > > The CompressContent processor uses the SnappyOutputStream class from > snappy-java project. As listed on > [https://github.com/xerial/snappy-java|https://github.com/xerial/snappy-java,] > this output will be incompatible with > org.apache.hadoop.io.compress.SnappyCodec used for default in spark. When you > try to read snappy files produced by this processor from Spark, you will get > an empty dataframe. > One can deal with the data in Spark by using the SnappyInputStream on the raw > files and not dealing with the SnappyCodec in spark, but it is not obvious at > first glance why the default doesn't work. > Is there a way to add HadoopCompatibleSnappy as an option like Snappy Framed > is offered? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (NIFI-7506) CompressContent Add Snappy-Hadoop
Noe created NIFI-7506: - Summary: CompressContent Add Snappy-Hadoop Key: NIFI-7506 URL: https://issues.apache.org/jira/browse/NIFI-7506 Project: Apache NiFi Issue Type: Improvement Reporter: Noe I have been using this recommendation for a few months now and want to contribute is back Bryan Bende Nov 26, 2019, 12:54 PM to users Not sure if this is relevant, but snappy-java has a specific SnappyHadoopCompatibleOutputStream so CompressContent could offer a third snappy option like "snappy-hadoop" which used that. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (NIFI-3349) GetSplunk Should Periodically Re-Authenticate
[
https://issues.apache.org/jira/browse/NIFI-3349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16163493#comment-16163493
]
Noe commented on NIFI-3349:
---
submitted pull request
https://github.com/apache/nifi/pull/2149
> GetSplunk Should Periodically Re-Authenticate
> -
>
> Key: NIFI-3349
> URL: https://issues.apache.org/jira/browse/NIFI-3349
> Project: Apache NiFi
> Issue Type: Bug
>Affects Versions: 1.0.0, 0.6.0, 0.7.0, 0.6.1, 1.1.0, 0.7.1, 1.1.1, 1.0.1
>Reporter: Bryan Bende
>Priority: Minor
>
> The first time the processor executes, it lazily initializes the Splunk
> Service object:
> https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-splunk-bundle/nifi-splunk-processors/src/main/java/org/apache/nifi/processors/splunk/GetSplunk.java#L372-L377
> As part of this initialization, the Splunk service calls a login method like
> this:
> {code}
> public Service login(String username, String password) {
> this.username = username;
> this.password = password;
> Args args = new Args();
> args.put("username", username);
> args.put("password", password);
> args.put("cookie", "1");
> ResponseMessage response = post("/services/auth/login", args);
> String sessionKey = Xml.parse(response.getContent())
> .getElementsByTagName("sessionKey")
> .item(0)
> .getTextContent();
> this.token = "Splunk " + sessionKey;
> this.version = this.getInfo().getVersion();
> if (versionCompare("4.3") >= 0)
> this.passwordEndPoint = "storage/passwords";
> return this;
> }
> {code}
> Since this only happens the first time the processor executes, it will only
> happen again if you stop and start the processor. If the processor has been
> running long enough that session probably expired and the processor is
> continuing to attempt to execute.
> We should periodically call service.login() in a timer thread.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (NIFI-3349) GetSplunk Should Periodically Re-Authenticate
[
https://issues.apache.org/jira/browse/NIFI-3349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16103153#comment-16103153
]
Noe edited comment on NIFI-3349 at 7/27/17 12:35 PM:
-
GetSplunk is periodically having this issue and think it is related:
ERROR [Timer-Driven Process Thread-29] o.a.nifi.processors.splunk.GetSplunk
GetSplunk[id=57083ec7-c0ef-152a-a952-2c31764dc675]
GetSplunk[id=57083ec7-c0ef-152a-a952-2c31764dc675] failed to process due to
com.splunk.HttpException: HTTP 401 -- {"messages":[{"type":"WARN","text":"call
not properly authenticated"}
This happens on [line
461|https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-splunk-bundle/nifi-splunk-processors/src/main/java/org/apache/nifi/processors/splunk/GetSplunk.java#L461https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-splunk-bundle/nifi-splunk-processors/src/main/java/org/apache/nifi/processors/splunk/GetSplunk.java#L461]
Would like to catch and call service.login() at least once, as well?
was (Author: ndet...@minerkasch.com):
GetSplunk is periodically having this issue and think it is related:
ERROR [Timer-Driven Process Thread-29] o.a.nifi.processors.splunk.GetSplunk
GetSplunk[id=57083ec7-c0ef-152a-a952-2c31764dc675]
GetSplunk[id=57083ec7-c0ef-152a-a952-2c31764dc675] failed to process due to
com.splunk.HttpException: HTTP 401 -- {"messages":[{"type":"WARN","text":"call
not properly authenticated"}
This happens on [line
461|https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-splunk-bundle/nifi-splunk-processors/src/main/java/org/apache/nifi/processors/splunk/GetSplunk.java#L461https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-splunk-bundle/nifi-splunk-processors/src/main/java/org/apache/nifi/processors/splunk/GetSplunk.java#L461]
Would like to catch and call service.login() as well?
> GetSplunk Should Periodically Re-Authenticate
> -
>
> Key: NIFI-3349
> URL: https://issues.apache.org/jira/browse/NIFI-3349
> Project: Apache NiFi
> Issue Type: Bug
>Affects Versions: 1.0.0, 0.6.0, 0.7.0, 0.6.1, 1.1.0, 0.7.1, 1.1.1, 1.0.1
>Reporter: Bryan Bende
>Priority: Minor
>
> The first time the processor executes, it lazily initializes the Splunk
> Service object:
> https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-splunk-bundle/nifi-splunk-processors/src/main/java/org/apache/nifi/processors/splunk/GetSplunk.java#L372-L377
> As part of this initialization, the Splunk service calls a login method like
> this:
> {code}
> public Service login(String username, String password) {
> this.username = username;
> this.password = password;
> Args args = new Args();
> args.put("username", username);
> args.put("password", password);
> args.put("cookie", "1");
> ResponseMessage response = post("/services/auth/login", args);
> String sessionKey = Xml.parse(response.getContent())
> .getElementsByTagName("sessionKey")
> .item(0)
> .getTextContent();
> this.token = "Splunk " + sessionKey;
> this.version = this.getInfo().getVersion();
> if (versionCompare("4.3") >= 0)
> this.passwordEndPoint = "storage/passwords";
> return this;
> }
> {code}
> Since this only happens the first time the processor executes, it will only
> happen again if you stop and start the processor. If the processor has been
> running long enough that session probably expired and the processor is
> continuing to attempt to execute.
> We should periodically call service.login() in a timer thread.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (NIFI-3349) GetSplunk Should Periodically Re-Authenticate
[
https://issues.apache.org/jira/browse/NIFI-3349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16103153#comment-16103153
]
Noe edited comment on NIFI-3349 at 7/27/17 12:34 PM:
-
GetSplunk is periodically having this issue and think it is related:
ERROR [Timer-Driven Process Thread-29] o.a.nifi.processors.splunk.GetSplunk
GetSplunk[id=57083ec7-c0ef-152a-a952-2c31764dc675]
GetSplunk[id=57083ec7-c0ef-152a-a952-2c31764dc675] failed to process due to
com.splunk.HttpException: HTTP 401 -- {"messages":[{"type":"WARN","text":"call
not properly authenticated"}]}; rolling back session:
This happens on [line
461|https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-splunk-bundle/nifi-splunk-processors/src/main/java/org/apache/nifi/processors/splunk/GetSplunk.java#L461https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-splunk-bundle/nifi-splunk-processors/src/main/java/org/apache/nifi/processors/splunk/GetSplunk.java#L461]
Would like to catch and call service.login() as well?
was (Author: ndet...@minerkasch.com):
GetSplunk is periodically having this issue and think it is related:
ERROR [Timer-Driven Process Thread-29] o.a.nifi.processors.splunk.GetSplunk
GetSplunk[id=57083ec7-c0ef-152a-a952-2c31764dc675]
GetSplunk[id=57083ec7-c0ef-152a-a952-2c31764dc675] failed to process due to
com.splunk.HttpException: HTTP 401 -- {"messages":[{"type":"WARN","text":"call
not properly authenticated"}]}; rolling back session: com.splunk.HttpException:
HTTP 401 -- {"messages":[{"type":"WARN","text":"call not properly
authenticated"}]}
This happens on [line
461|https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-splunk-bundle/nifi-splunk-processors/src/main/java/org/apache/nifi/processors/splunk/GetSplunk.java#L461https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-splunk-bundle/nifi-splunk-processors/src/main/java/org/apache/nifi/processors/splunk/GetSplunk.java#L461]
Would like to catch and call service.login() as well?
> GetSplunk Should Periodically Re-Authenticate
> -
>
> Key: NIFI-3349
> URL: https://issues.apache.org/jira/browse/NIFI-3349
> Project: Apache NiFi
> Issue Type: Bug
>Affects Versions: 1.0.0, 0.6.0, 0.7.0, 0.6.1, 1.1.0, 0.7.1, 1.1.1, 1.0.1
>Reporter: Bryan Bende
>Priority: Minor
>
> The first time the processor executes, it lazily initializes the Splunk
> Service object:
> https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-splunk-bundle/nifi-splunk-processors/src/main/java/org/apache/nifi/processors/splunk/GetSplunk.java#L372-L377
> As part of this initialization, the Splunk service calls a login method like
> this:
> {code}
> public Service login(String username, String password) {
> this.username = username;
> this.password = password;
> Args args = new Args();
> args.put("username", username);
> args.put("password", password);
> args.put("cookie", "1");
> ResponseMessage response = post("/services/auth/login", args);
> String sessionKey = Xml.parse(response.getContent())
> .getElementsByTagName("sessionKey")
> .item(0)
> .getTextContent();
> this.token = "Splunk " + sessionKey;
> this.version = this.getInfo().getVersion();
> if (versionCompare("4.3") >= 0)
> this.passwordEndPoint = "storage/passwords";
> return this;
> }
> {code}
> Since this only happens the first time the processor executes, it will only
> happen again if you stop and start the processor. If the processor has been
> running long enough that session probably expired and the processor is
> continuing to attempt to execute.
> We should periodically call service.login() in a timer thread.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (NIFI-3349) GetSplunk Should Periodically Re-Authenticate
[
https://issues.apache.org/jira/browse/NIFI-3349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16103153#comment-16103153
]
Noe edited comment on NIFI-3349 at 7/27/17 12:34 PM:
-
GetSplunk is periodically having this issue and think it is related:
ERROR [Timer-Driven Process Thread-29] o.a.nifi.processors.splunk.GetSplunk
GetSplunk[id=57083ec7-c0ef-152a-a952-2c31764dc675]
GetSplunk[id=57083ec7-c0ef-152a-a952-2c31764dc675] failed to process due to
com.splunk.HttpException: HTTP 401 -- {"messages":[{"type":"WARN","text":"call
not properly authenticated"}
This happens on [line
461|https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-splunk-bundle/nifi-splunk-processors/src/main/java/org/apache/nifi/processors/splunk/GetSplunk.java#L461https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-splunk-bundle/nifi-splunk-processors/src/main/java/org/apache/nifi/processors/splunk/GetSplunk.java#L461]
Would like to catch and call service.login() as well?
was (Author: ndet...@minerkasch.com):
GetSplunk is periodically having this issue and think it is related:
ERROR [Timer-Driven Process Thread-29] o.a.nifi.processors.splunk.GetSplunk
GetSplunk[id=57083ec7-c0ef-152a-a952-2c31764dc675]
GetSplunk[id=57083ec7-c0ef-152a-a952-2c31764dc675] failed to process due to
com.splunk.HttpException: HTTP 401 -- {"messages":[{"type":"WARN","text":"call
not properly authenticated"}]}; rolling back session:
This happens on [line
461|https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-splunk-bundle/nifi-splunk-processors/src/main/java/org/apache/nifi/processors/splunk/GetSplunk.java#L461https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-splunk-bundle/nifi-splunk-processors/src/main/java/org/apache/nifi/processors/splunk/GetSplunk.java#L461]
Would like to catch and call service.login() as well?
> GetSplunk Should Periodically Re-Authenticate
> -
>
> Key: NIFI-3349
> URL: https://issues.apache.org/jira/browse/NIFI-3349
> Project: Apache NiFi
> Issue Type: Bug
>Affects Versions: 1.0.0, 0.6.0, 0.7.0, 0.6.1, 1.1.0, 0.7.1, 1.1.1, 1.0.1
>Reporter: Bryan Bende
>Priority: Minor
>
> The first time the processor executes, it lazily initializes the Splunk
> Service object:
> https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-splunk-bundle/nifi-splunk-processors/src/main/java/org/apache/nifi/processors/splunk/GetSplunk.java#L372-L377
> As part of this initialization, the Splunk service calls a login method like
> this:
> {code}
> public Service login(String username, String password) {
> this.username = username;
> this.password = password;
> Args args = new Args();
> args.put("username", username);
> args.put("password", password);
> args.put("cookie", "1");
> ResponseMessage response = post("/services/auth/login", args);
> String sessionKey = Xml.parse(response.getContent())
> .getElementsByTagName("sessionKey")
> .item(0)
> .getTextContent();
> this.token = "Splunk " + sessionKey;
> this.version = this.getInfo().getVersion();
> if (versionCompare("4.3") >= 0)
> this.passwordEndPoint = "storage/passwords";
> return this;
> }
> {code}
> Since this only happens the first time the processor executes, it will only
> happen again if you stop and start the processor. If the processor has been
> running long enough that session probably expired and the processor is
> continuing to attempt to execute.
> We should periodically call service.login() in a timer thread.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (NIFI-3349) GetSplunk Should Periodically Re-Authenticate
[
https://issues.apache.org/jira/browse/NIFI-3349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16103153#comment-16103153
]
Noe commented on NIFI-3349:
---
GetSplunk is periodically having this issue and think it is related:
ERROR [Timer-Driven Process Thread-29] o.a.nifi.processors.splunk.GetSplunk
GetSplunk[id=57083ec7-c0ef-152a-a952-2c31764dc675]
GetSplunk[id=57083ec7-c0ef-152a-a952-2c31764dc675] failed to process due to
com.splunk.HttpException: HTTP 401 -- {"messages":[{"type":"WARN","text":"call
not properly authenticated"}]}; rolling back session: com.splunk.HttpException:
HTTP 401 -- {"messages":[{"type":"WARN","text":"call not properly
authenticated"}]}
This happens on [line
461|https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-splunk-bundle/nifi-splunk-processors/src/main/java/org/apache/nifi/processors/splunk/GetSplunk.java#L461https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-splunk-bundle/nifi-splunk-processors/src/main/java/org/apache/nifi/processors/splunk/GetSplunk.java#L461]
Would like to catch and call service.login() as well?
> GetSplunk Should Periodically Re-Authenticate
> -
>
> Key: NIFI-3349
> URL: https://issues.apache.org/jira/browse/NIFI-3349
> Project: Apache NiFi
> Issue Type: Bug
>Affects Versions: 1.0.0, 0.6.0, 0.7.0, 0.6.1, 1.1.0, 0.7.1, 1.1.1, 1.0.1
>Reporter: Bryan Bende
>Priority: Minor
>
> The first time the processor executes, it lazily initializes the Splunk
> Service object:
> https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-splunk-bundle/nifi-splunk-processors/src/main/java/org/apache/nifi/processors/splunk/GetSplunk.java#L372-L377
> As part of this initialization, the Splunk service calls a login method like
> this:
> {code}
> public Service login(String username, String password) {
> this.username = username;
> this.password = password;
> Args args = new Args();
> args.put("username", username);
> args.put("password", password);
> args.put("cookie", "1");
> ResponseMessage response = post("/services/auth/login", args);
> String sessionKey = Xml.parse(response.getContent())
> .getElementsByTagName("sessionKey")
> .item(0)
> .getTextContent();
> this.token = "Splunk " + sessionKey;
> this.version = this.getInfo().getVersion();
> if (versionCompare("4.3") >= 0)
> this.passwordEndPoint = "storage/passwords";
> return this;
> }
> {code}
> Since this only happens the first time the processor executes, it will only
> happen again if you stop and start the processor. If the processor has been
> running long enough that session probably expired and the processor is
> continuing to attempt to execute.
> We should periodically call service.login() in a timer thread.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (NIFI-1985) ListenTCP should allow setting incoming message delimiter
[ https://issues.apache.org/jira/browse/NIFI-1985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16058105#comment-16058105 ] Noe commented on NIFI-1985: --- any progress on this? > ListenTCP should allow setting incoming message delimiter > - > > Key: NIFI-1985 > URL: https://issues.apache.org/jira/browse/NIFI-1985 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 0.6.0, 0.6.1 >Reporter: Bryan Bende >Assignee: Bryan Bende >Priority: Minor > > Currently ListenTCP reads incoming messages separating them by "/n" and this > is hard-coded. It would be useful to expose a property on the processor that > allowed this to be changed by the user. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
