[jira] [Commented] (NIFI-7057) Fix Script Permissions For Docker Integration Test
[ https://issues.apache.org/jira/browse/NIFI-7057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17128374#comment-17128374 ] Makarov Vasiliy Nicolaevich commented on NIFI-7057: --- I would like to participate in this issue. Looking forward to being added to the contributors. > Fix Script Permissions For Docker Integration Test > -- > > Key: NIFI-7057 > URL: https://issues.apache.org/jira/browse/NIFI-7057 > Project: Apache NiFi > Issue Type: Bug >Reporter: Shawn Weeks >Priority: Trivial > > The following files need to have their permissions updated for the Docker > profile to run it's tests. I'll add more files if I find them. > chmod 755 ./nifi-toolkit-assembly/docker/tests/exit-codes.sh > chmod 755 ./nifi-toolkit/nifi-toolkit-assembly/docker/tests/tls-toolkit.sh > chmod 755 ./nifi-docker/dockermaven/integration-test.sh > chmod 755 ./nifi-docker/dockermaven/sh/*.sh > chmod 755 ./nifi-docker/dockerhub/sh/*.sh -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (NIFI-7035) Don't spam logs with Apache Curator errors on Zookeeper Disconnect
[
https://issues.apache.org/jira/browse/NIFI-7035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17128375#comment-17128375
]
Makarov Vasiliy Nicolaevich commented on NIFI-7035:
---
I would like to participate in this issue too. Looking forward to being added
to the contributors.
> Don't spam logs with Apache Curator errors on Zookeeper Disconnect
> --
>
> Key: NIFI-7035
> URL: https://issues.apache.org/jira/browse/NIFI-7035
> Project: Apache NiFi
> Issue Type: Improvement
>Reporter: Shawn Weeks
>Priority: Trivial
>
> Sometimes when you startup NiFi and not all of the Zookeeper nodes aren't up
> it fills the logs with Apache Curator errors like this one. We should be able
> to improve this a bit as logging the same error repeatedly isn't helpful.
> {code:java}
> 2020-01-16 08:58:28,767 ERROR [Curator-Framework-0]
> o.a.c.f.imps.CuratorFrameworkImpl Background retry gave up
> org.apache.curator.CuratorConnectionLossException: KeeperErrorCode =
> ConnectionLoss
> at
> org.apache.curator.framework.imps.CuratorFrameworkImpl.performBackgroundOperation(CuratorFrameworkImpl.java:972)
> at
> org.apache.curator.framework.imps.CuratorFrameworkImpl.backgroundOperationsLoop(CuratorFrameworkImpl.java:943)
> at
> org.apache.curator.framework.imps.CuratorFrameworkImpl.access$300(CuratorFrameworkImpl.java:66)
> at
> org.apache.curator.framework.imps.CuratorFrameworkImpl$4.call(CuratorFrameworkImpl.java:346)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (NIFI-7057) Fix Script Permissions For Docker Integration Test
[ https://issues.apache.org/jira/browse/NIFI-7057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Makarov Vasiliy Nicolaevich reassigned NIFI-7057: - Assignee: Makarov Vasiliy Nicolaevich > Fix Script Permissions For Docker Integration Test > -- > > Key: NIFI-7057 > URL: https://issues.apache.org/jira/browse/NIFI-7057 > Project: Apache NiFi > Issue Type: Bug >Reporter: Shawn Weeks >Assignee: Makarov Vasiliy Nicolaevich >Priority: Trivial > > The following files need to have their permissions updated for the Docker > profile to run it's tests. I'll add more files if I find them. > chmod 755 ./nifi-toolkit-assembly/docker/tests/exit-codes.sh > chmod 755 ./nifi-toolkit/nifi-toolkit-assembly/docker/tests/tls-toolkit.sh > chmod 755 ./nifi-docker/dockermaven/integration-test.sh > chmod 755 ./nifi-docker/dockermaven/sh/*.sh > chmod 755 ./nifi-docker/dockerhub/sh/*.sh -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (NIFI-7035) Don't spam logs with Apache Curator errors on Zookeeper Disconnect
[
https://issues.apache.org/jira/browse/NIFI-7035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Makarov Vasiliy Nicolaevich reassigned NIFI-7035:
-
Assignee: Makarov Vasiliy Nicolaevich
> Don't spam logs with Apache Curator errors on Zookeeper Disconnect
> --
>
> Key: NIFI-7035
> URL: https://issues.apache.org/jira/browse/NIFI-7035
> Project: Apache NiFi
> Issue Type: Improvement
>Reporter: Shawn Weeks
>Assignee: Makarov Vasiliy Nicolaevich
>Priority: Trivial
>
> Sometimes when you startup NiFi and not all of the Zookeeper nodes aren't up
> it fills the logs with Apache Curator errors like this one. We should be able
> to improve this a bit as logging the same error repeatedly isn't helpful.
> {code:java}
> 2020-01-16 08:58:28,767 ERROR [Curator-Framework-0]
> o.a.c.f.imps.CuratorFrameworkImpl Background retry gave up
> org.apache.curator.CuratorConnectionLossException: KeeperErrorCode =
> ConnectionLoss
> at
> org.apache.curator.framework.imps.CuratorFrameworkImpl.performBackgroundOperation(CuratorFrameworkImpl.java:972)
> at
> org.apache.curator.framework.imps.CuratorFrameworkImpl.backgroundOperationsLoop(CuratorFrameworkImpl.java:943)
> at
> org.apache.curator.framework.imps.CuratorFrameworkImpl.access$300(CuratorFrameworkImpl.java:66)
> at
> org.apache.curator.framework.imps.CuratorFrameworkImpl$4.call(CuratorFrameworkImpl.java:346)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (NIFI-7035) Don't spam logs with Apache Curator errors on Zookeeper Disconnect
[
https://issues.apache.org/jira/browse/NIFI-7035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17129295#comment-17129295
]
Makarov Vasiliy Nicolaevich commented on NIFI-7035:
---
[~Absolutesantaja] [~rabikumar.kc]
Ok, so I have reproduced the issue. It occurs when NiFi is in cluster mode but
has no access to one of the Zookeper nodes (embedded in my case).
I will try to limit it / filter excessive logs out it on Logbase config part
because as I see we don't explicitly log this error in NiFi code.
Also, this task is related it seems to:
[https://issues.apache.org/jira/browse/NIFI-3731
] [~randgalt] indicated there that Curator has a switch to log only the first
error as an ERROR level and others as DEBUG level. Don't know if it helps in
the situation with zookeeper only.
Any advice would be appreciated though.
> Don't spam logs with Apache Curator errors on Zookeeper Disconnect
> --
>
> Key: NIFI-7035
> URL: https://issues.apache.org/jira/browse/NIFI-7035
> Project: Apache NiFi
> Issue Type: Improvement
>Reporter: Shawn Weeks
>Assignee: Makarov Vasiliy Nicolaevich
>Priority: Trivial
>
> Sometimes when you startup NiFi and not all of the Zookeeper nodes aren't up
> it fills the logs with Apache Curator errors like this one. We should be able
> to improve this a bit as logging the same error repeatedly isn't helpful.
> {code:java}
> 2020-01-16 08:58:28,767 ERROR [Curator-Framework-0]
> o.a.c.f.imps.CuratorFrameworkImpl Background retry gave up
> org.apache.curator.CuratorConnectionLossException: KeeperErrorCode =
> ConnectionLoss
> at
> org.apache.curator.framework.imps.CuratorFrameworkImpl.performBackgroundOperation(CuratorFrameworkImpl.java:972)
> at
> org.apache.curator.framework.imps.CuratorFrameworkImpl.backgroundOperationsLoop(CuratorFrameworkImpl.java:943)
> at
> org.apache.curator.framework.imps.CuratorFrameworkImpl.access$300(CuratorFrameworkImpl.java:66)
> at
> org.apache.curator.framework.imps.CuratorFrameworkImpl$4.call(CuratorFrameworkImpl.java:346)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (NIFI-7035) Don't spam logs with Apache Curator errors on Zookeeper Disconnect
[
https://issues.apache.org/jira/browse/NIFI-7035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17129295#comment-17129295
]
Makarov Vasiliy Nicolaevich edited comment on NIFI-7035 at 6/9/20, 1:57 PM:
[~Absolutesantaja] [~rabikumar.kc]
Ok, so I have reproduced the issue. It occurs when NiFi is in cluster mode but
has no access to one of the Zookeper nodes (embedded in my case).
I will try to limit it / filter excessive logs out it on Logbase config part
because as I see we don't explicitly log this error in NiFi code.
Also, this task is related it seems to:
[https://issues.apache.org/jira/browse/NIFI-3731]
[~randgalt] indicated there that Curator has a switch to log only the first
error as an ERROR level and others as DEBUG level. Don't know if it helps in
the situation with zookeeper only.
Any advice would be appreciated though.
was (Author: feitgraph):
[~Absolutesantaja] [~rabikumar.kc]
Ok, so I have reproduced the issue. It occurs when NiFi is in cluster mode but
has no access to one of the Zookeper nodes (embedded in my case).
I will try to limit it / filter excessive logs out it on Logbase config part
because as I see we don't explicitly log this error in NiFi code.
Also, this task is related it seems to:
[https://issues.apache.org/jira/browse/NIFI-3731
] [~randgalt] indicated there that Curator has a switch to log only the first
error as an ERROR level and others as DEBUG level. Don't know if it helps in
the situation with zookeeper only.
Any advice would be appreciated though.
> Don't spam logs with Apache Curator errors on Zookeeper Disconnect
> --
>
> Key: NIFI-7035
> URL: https://issues.apache.org/jira/browse/NIFI-7035
> Project: Apache NiFi
> Issue Type: Improvement
>Reporter: Shawn Weeks
>Assignee: Makarov Vasiliy Nicolaevich
>Priority: Trivial
>
> Sometimes when you startup NiFi and not all of the Zookeeper nodes aren't up
> it fills the logs with Apache Curator errors like this one. We should be able
> to improve this a bit as logging the same error repeatedly isn't helpful.
> {code:java}
> 2020-01-16 08:58:28,767 ERROR [Curator-Framework-0]
> o.a.c.f.imps.CuratorFrameworkImpl Background retry gave up
> org.apache.curator.CuratorConnectionLossException: KeeperErrorCode =
> ConnectionLoss
> at
> org.apache.curator.framework.imps.CuratorFrameworkImpl.performBackgroundOperation(CuratorFrameworkImpl.java:972)
> at
> org.apache.curator.framework.imps.CuratorFrameworkImpl.backgroundOperationsLoop(CuratorFrameworkImpl.java:943)
> at
> org.apache.curator.framework.imps.CuratorFrameworkImpl.access$300(CuratorFrameworkImpl.java:66)
> at
> org.apache.curator.framework.imps.CuratorFrameworkImpl$4.call(CuratorFrameworkImpl.java:346)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (NIFI-7035) Don't spam logs with Apache Curator errors on Zookeeper Disconnect
[
https://issues.apache.org/jira/browse/NIFI-7035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17130751#comment-17130751
]
Makarov Vasiliy Nicolaevich commented on NIFI-7035:
---
[~markap14]
Good point, Mark, I have tried it out and it seems to fix the problem of
excessive logging. These exceptions are no longer spammed in the NiFi log.
I will create PR and attach steps to reproduce the issue and also logs
references.
> Don't spam logs with Apache Curator errors on Zookeeper Disconnect
> --
>
> Key: NIFI-7035
> URL: https://issues.apache.org/jira/browse/NIFI-7035
> Project: Apache NiFi
> Issue Type: Improvement
>Reporter: Shawn Weeks
>Assignee: Makarov Vasiliy Nicolaevich
>Priority: Trivial
>
> Sometimes when you startup NiFi and not all of the Zookeeper nodes aren't up
> it fills the logs with Apache Curator errors like this one. We should be able
> to improve this a bit as logging the same error repeatedly isn't helpful.
> {code:java}
> 2020-01-16 08:58:28,767 ERROR [Curator-Framework-0]
> o.a.c.f.imps.CuratorFrameworkImpl Background retry gave up
> org.apache.curator.CuratorConnectionLossException: KeeperErrorCode =
> ConnectionLoss
> at
> org.apache.curator.framework.imps.CuratorFrameworkImpl.performBackgroundOperation(CuratorFrameworkImpl.java:972)
> at
> org.apache.curator.framework.imps.CuratorFrameworkImpl.backgroundOperationsLoop(CuratorFrameworkImpl.java:943)
> at
> org.apache.curator.framework.imps.CuratorFrameworkImpl.access$300(CuratorFrameworkImpl.java:66)
> at
> org.apache.curator.framework.imps.CuratorFrameworkImpl$4.call(CuratorFrameworkImpl.java:346)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (NIFI-7057) Fix Script Permissions For Docker Integration Test
[ https://issues.apache.org/jira/browse/NIFI-7057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17133128#comment-17133128 ] Makarov Vasiliy Nicolaevich commented on NIFI-7057: --- I have checked these files out - they all are with correct 775 permission status. So I think issue is already resolved. [~Absolutesantaja] One question is should we move these permissions in Dockerfile like in NIFI-7080 ? > Fix Script Permissions For Docker Integration Test > -- > > Key: NIFI-7057 > URL: https://issues.apache.org/jira/browse/NIFI-7057 > Project: Apache NiFi > Issue Type: Bug >Reporter: Shawn Weeks >Assignee: Makarov Vasiliy Nicolaevich >Priority: Trivial > > The following files need to have their permissions updated for the Docker > profile to run it's tests. I'll add more files if I find them. > chmod 755 ./nifi-toolkit-assembly/docker/tests/exit-codes.sh > chmod 755 ./nifi-toolkit/nifi-toolkit-assembly/docker/tests/tls-toolkit.sh > chmod 755 ./nifi-docker/dockermaven/integration-test.sh > chmod 755 ./nifi-docker/dockermaven/sh/*.sh > chmod 755 ./nifi-docker/dockerhub/sh/*.sh -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (NIFI-6163) Reporting task can be set to RUNNING from REST API when invalid
[
https://issues.apache.org/jira/browse/NIFI-6163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Makarov Vasiliy Nicolaevich reassigned NIFI-6163:
-
Assignee: Makarov Vasiliy Nicolaevich
> Reporting task can be set to RUNNING from REST API when invalid
> ---
>
> Key: NIFI-6163
> URL: https://issues.apache.org/jira/browse/NIFI-6163
> Project: Apache NiFi
> Issue Type: Bug
>Affects Versions: 1.9.1
>Reporter: Bryan Bende
>Assignee: Makarov Vasiliy Nicolaevich
>Priority: Minor
>
> Using the REST API you can submit a request to start a reporting task that
> has validation errors using a curl command like this:
> {code:java}
> curl -X PUT -H Content-Type:application/json
> "http://localhost:8080/nifi-api/reporting-tasks/ca0808a7-0169-1000-9546-62009238a9da/run-status";
> -d
> '{"revision":{"clientId":"ca05c584-0169-1000-497d-4c35dd4f2a58","version":7},"disconnectedNodeAcknowledged":false,"state":"RUNNING"}'{code}
> This call succeeds and if you refresh the UI it will show as running, even
> though it should never have been allowed to be running since it was invalid.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (NIFI-7488) Listening Port property on HandleHttpRequest is not validated when Variable registry is used
[ https://issues.apache.org/jira/browse/NIFI-7488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Makarov Vasiliy Nicolaevich updated NIFI-7488: -- Attachment: image-2020-06-19-13-31-22-457.png > Listening Port property on HandleHttpRequest is not validated when Variable > registry is used > > > Key: NIFI-7488 > URL: https://issues.apache.org/jira/browse/NIFI-7488 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Alessandro D'Armiento >Priority: Minor > Attachments: image-2020-06-19-13-31-22-457.png > > Time Spent: 40m > Remaining Estimate: 0h > > The value of the listening port is not validated against negative or too high > values when the variable registry is used. > Related with #NIFI-7479 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (NIFI-7488) Listening Port property on HandleHttpRequest is not validated when Variable registry is used
[ https://issues.apache.org/jira/browse/NIFI-7488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Makarov Vasiliy Nicolaevich updated NIFI-7488: -- Attachment: image-2020-06-19-13-32-27-026.png > Listening Port property on HandleHttpRequest is not validated when Variable > registry is used > > > Key: NIFI-7488 > URL: https://issues.apache.org/jira/browse/NIFI-7488 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Alessandro D'Armiento >Priority: Minor > Attachments: image-2020-06-19-13-31-22-457.png, > image-2020-06-19-13-32-27-026.png > > Time Spent: 40m > Remaining Estimate: 0h > > The value of the listening port is not validated against negative or too high > values when the variable registry is used. > Related with #NIFI-7479 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (NIFI-7488) Listening Port property on HandleHttpRequest is not validated when Variable registry is used
[ https://issues.apache.org/jira/browse/NIFI-7488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17140421#comment-17140421 ] Makarov Vasiliy Nicolaevich commented on NIFI-7488: --- I could not reproduce the issue. Tried to set up the test parameter to -100 in the processor group. After which validation errors occurred. !image-2020-06-19-13-31-22-457.png! !image-2020-06-19-13-32-27-026.png! > Listening Port property on HandleHttpRequest is not validated when Variable > registry is used > > > Key: NIFI-7488 > URL: https://issues.apache.org/jira/browse/NIFI-7488 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Alessandro D'Armiento >Priority: Minor > Attachments: image-2020-06-19-13-31-22-457.png, > image-2020-06-19-13-32-27-026.png > > Time Spent: 40m > Remaining Estimate: 0h > > The value of the listening port is not validated against negative or too high > values when the variable registry is used. > Related with #NIFI-7479 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (NIFI-7562) asciidoctor-maven-plugin error when buildin on windows
Makarov Vasiliy Nicolaevich created NIFI-7562: - Summary: asciidoctor-maven-plugin error when buildin on windows Key: NIFI-7562 URL: https://issues.apache.org/jira/browse/NIFI-7562 Project: Apache NiFi Issue Type: Bug Reporter: Makarov Vasiliy Nicolaevich Attachments: log.txt When building NiFi on windows I encounter such an error with _asciidoctor-maven-plugin:_ ~_[INFO] BUILD FAILURE_~ ~_[INFO] _~ ~_[INFO] Total time: 01:22 min (Wall Clock)_~ ~_[INFO] Finished at: 2020-06-11T13:42:20+03:00_~ ~_[INFO] _~ ~_[ERROR] Failed to execute goal org.asciidoctor:asciidoctor-maven-plugin:1.5.2:process-asciidoc (output-html) on project nifi-docs: Execution output-html of goal org.asciidoctor:asciidoctor-maven-plugin:1.5.2:process-asciidoc failed: (LoadError) no such file to load -- asciidoctor -> [Help 1]_~ ~_[ERROR]_~ ~_[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch._~ ~_[ERROR] Re-run Maven using the -X switch to enable full debug logging._~ ~_[ERROR]_~ ~_[ERROR] For more information about the errors and possible solutions, please read the following articles:_~ ~_[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException_~ ~_[ERROR]_~ ~_[ERROR] After correcting the problems, you can resume the build with the command_~ ~_[ERROR] mvn -rf :nifi-docs_~ I have temporarily resolved this issue by commenting out these rows in nifi-docs pom.xml:
[jira] [Commented] (NIFI-6603) Variables: There is no way to cancel creating a new variable unless a variable name is provided.
[ https://issues.apache.org/jira/browse/NIFI-6603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17142924#comment-17142924 ] Makarov Vasiliy Nicolaevich commented on NIFI-6603: --- You can cancel it by "ESC" button. But indeed there are no "cancel" button there. > Variables: There is no way to cancel creating a new variable unless a > variable name is provided. > > > Key: NIFI-6603 > URL: https://issues.apache.org/jira/browse/NIFI-6603 > Project: Apache NiFi > Issue Type: Improvement > Components: Core UI >Reporter: Andrew M. Lim >Priority: Minor > > Open the variables window and select "+" . In the New Variable window do not > enter a value for the Variable Name field and select "OK". A Configuration > Error dialog is shown, select "OK". There is no way for the user to stop > variable creation without entering a name and then selecting Cancel from the > Variables window. We should add a "Cancel" button to the "New Variable" > window. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (NIFI-6603) Variables: There is no way to cancel creating a new variable unless a variable name is provided.
[ https://issues.apache.org/jira/browse/NIFI-6603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Makarov Vasiliy Nicolaevich reassigned NIFI-6603: - Assignee: Makarov Vasiliy Nicolaevich > Variables: There is no way to cancel creating a new variable unless a > variable name is provided. > > > Key: NIFI-6603 > URL: https://issues.apache.org/jira/browse/NIFI-6603 > Project: Apache NiFi > Issue Type: Improvement > Components: Core UI >Reporter: Andrew M. Lim >Assignee: Makarov Vasiliy Nicolaevich >Priority: Minor > > Open the variables window and select "+" . In the New Variable window do not > enter a value for the Variable Name field and select "OK". A Configuration > Error dialog is shown, select "OK". There is no way for the user to stop > variable creation without entering a name and then selecting Cancel from the > Variables window. We should add a "Cancel" button to the "New Variable" > window. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (NIFI-6603) Variables: There is no way to cancel creating a new variable unless a variable name is provided.
[ https://issues.apache.org/jira/browse/NIFI-6603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Makarov Vasiliy Nicolaevich updated NIFI-6603: -- Status: Patch Available (was: In Progress) > Variables: There is no way to cancel creating a new variable unless a > variable name is provided. > > > Key: NIFI-6603 > URL: https://issues.apache.org/jira/browse/NIFI-6603 > Project: Apache NiFi > Issue Type: Improvement > Components: Core UI >Reporter: Andrew M. Lim >Assignee: Makarov Vasiliy Nicolaevich >Priority: Minor > Time Spent: 1h 10m > Remaining Estimate: 0h > > Open the variables window and select "+" . In the New Variable window do not > enter a value for the Variable Name field and select "OK". A Configuration > Error dialog is shown, select "OK". There is no way for the user to stop > variable creation without entering a name and then selecting Cancel from the > Variables window. We should add a "Cancel" button to the "New Variable" > window. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (NIFI-6163) Reporting task can be set to RUNNING from REST API when invalid
[
https://issues.apache.org/jira/browse/NIFI-6163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Makarov Vasiliy Nicolaevich updated NIFI-6163:
--
Affects Version/s: 1.12.0
1.11.4
Status: Patch Available (was: In Progress)
> Reporting task can be set to RUNNING from REST API when invalid
> ---
>
> Key: NIFI-6163
> URL: https://issues.apache.org/jira/browse/NIFI-6163
> Project: Apache NiFi
> Issue Type: Bug
>Affects Versions: 1.11.4, 1.9.1, 1.12.0
>Reporter: Bryan Bende
>Assignee: Makarov Vasiliy Nicolaevich
>Priority: Minor
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Using the REST API you can submit a request to start a reporting task that
> has validation errors using a curl command like this:
> {code:java}
> curl -X PUT -H Content-Type:application/json
> "http://localhost:8080/nifi-api/reporting-tasks/ca0808a7-0169-1000-9546-62009238a9da/run-status";
> -d
> '{"revision":{"clientId":"ca05c584-0169-1000-497d-4c35dd4f2a58","version":7},"disconnectedNodeAcknowledged":false,"state":"RUNNING"}'{code}
> This call succeeds and if you refresh the UI it will show as running, even
> though it should never have been allowed to be running since it was invalid.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (NIFI-7057) Fix Script Permissions For Docker Integration Test
[ https://issues.apache.org/jira/browse/NIFI-7057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Makarov Vasiliy Nicolaevich updated NIFI-7057: -- Status: Patch Available (was: In Progress) > Fix Script Permissions For Docker Integration Test > -- > > Key: NIFI-7057 > URL: https://issues.apache.org/jira/browse/NIFI-7057 > Project: Apache NiFi > Issue Type: Bug >Reporter: Shawn Weeks >Assignee: Makarov Vasiliy Nicolaevich >Priority: Trivial > > The following files need to have their permissions updated for the Docker > profile to run it's tests. I'll add more files if I find them. > chmod 755 ./nifi-toolkit-assembly/docker/tests/exit-codes.sh > chmod 755 ./nifi-toolkit/nifi-toolkit-assembly/docker/tests/tls-toolkit.sh > chmod 755 ./nifi-docker/dockermaven/integration-test.sh > chmod 755 ./nifi-docker/dockermaven/sh/*.sh > chmod 755 ./nifi-docker/dockerhub/sh/*.sh -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (NIFI-7190) CaptureChangeMySQL processor doesn't emit DDL events if SQL statement begins with a comment
[
https://issues.apache.org/jira/browse/NIFI-7190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Makarov Vasiliy Nicolaevich reassigned NIFI-7190:
-
Assignee: Makarov Vasiliy Nicolaevich
> CaptureChangeMySQL processor doesn't emit DDL events if SQL statement begins
> with a comment
> ---
>
> Key: NIFI-7190
> URL: https://issues.apache.org/jira/browse/NIFI-7190
> Project: Apache NiFi
> Issue Type: Bug
>Affects Versions: 1.11.2
>Reporter: Przemyslaw Dubaniewicz
>Assignee: Makarov Vasiliy Nicolaevich
>Priority: Minor
>
> The existing check for DDL Events doesn't take into account SQL statements
> that begin with a comment, in file:
> _nifi/nifi-nar-bundles/nifi-cdc/nifi-cdc-mysql-bundle/nifi-cdc-mysql-processors/src/main/java/org/apache/nifi/cdc/mysql/processors/CaptureChangeMySQL.java:821_
> {code:java}
> // Check for DDL events (alter table, e.g.). Normalize the query to do string
> matching on the type of change
> String normalizedQuery = sql.toLowerCase().trim().replaceAll(" {2,}", " ");
> if (normalizedQuery.startsWith("alter table")
> || normalizedQuery.startsWith("alter ignore table")
> || normalizedQuery.startsWith("create table")
> || normalizedQuery.startsWith("truncate table")
> || normalizedQuery.startsWith("rename table")
> || normalizedQuery.startsWith("drop table")
> || normalizedQuery.startsWith("drop database")) {code}
> SQL commands such as:
> {code:sql}
> /* ApplicationName=DataGrip 2019.2.4 */ alter table test_table
> drop column test_column
> {code}
> won't evaluate to true.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (NIFI-6601) Variables: "Apply" button should be greyed out if no changes have been made
[ https://issues.apache.org/jira/browse/NIFI-6601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17146107#comment-17146107 ] Makarov Vasiliy Nicolaevich commented on NIFI-6601: --- It seems that in processors UI apply button is not grayed out too. I have added Cancel button in the other ticket. > Variables: "Apply" button should be greyed out if no changes have been made > --- > > Key: NIFI-6601 > URL: https://issues.apache.org/jira/browse/NIFI-6601 > Project: Apache NiFi > Issue Type: Improvement > Components: Core UI >Reporter: Andrew M. Lim >Priority: Minor > > After opening the Variables window, the "Apply" button is available for > selection immediately even when no edits have been made to apply. If > selected, the window is closed which is what the Cancel button is for. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (NIFI-7190) CaptureChangeMySQL processor doesn't emit DDL events if SQL statement begins with a comment
[
https://issues.apache.org/jira/browse/NIFI-7190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Makarov Vasiliy Nicolaevich updated NIFI-7190:
--
Status: Patch Available (was: In Progress)
> CaptureChangeMySQL processor doesn't emit DDL events if SQL statement begins
> with a comment
> ---
>
> Key: NIFI-7190
> URL: https://issues.apache.org/jira/browse/NIFI-7190
> Project: Apache NiFi
> Issue Type: Bug
>Affects Versions: 1.11.2
>Reporter: Przemyslaw Dubaniewicz
>Assignee: Makarov Vasiliy Nicolaevich
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The existing check for DDL Events doesn't take into account SQL statements
> that begin with a comment, in file:
> _nifi/nifi-nar-bundles/nifi-cdc/nifi-cdc-mysql-bundle/nifi-cdc-mysql-processors/src/main/java/org/apache/nifi/cdc/mysql/processors/CaptureChangeMySQL.java:821_
> {code:java}
> // Check for DDL events (alter table, e.g.). Normalize the query to do string
> matching on the type of change
> String normalizedQuery = sql.toLowerCase().trim().replaceAll(" {2,}", " ");
> if (normalizedQuery.startsWith("alter table")
> || normalizedQuery.startsWith("alter ignore table")
> || normalizedQuery.startsWith("create table")
> || normalizedQuery.startsWith("truncate table")
> || normalizedQuery.startsWith("rename table")
> || normalizedQuery.startsWith("drop table")
> || normalizedQuery.startsWith("drop database")) {code}
> SQL commands such as:
> {code:sql}
> /* ApplicationName=DataGrip 2019.2.4 */ alter table test_table
> drop column test_column
> {code}
> won't evaluate to true.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (NIFI-7057) Fix Script Permissions For Docker Integration Test
[ https://issues.apache.org/jira/browse/NIFI-7057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Makarov Vasiliy Nicolaevich updated NIFI-7057: -- Resolution: Fixed Status: Resolved (was: Patch Available) > Fix Script Permissions For Docker Integration Test > -- > > Key: NIFI-7057 > URL: https://issues.apache.org/jira/browse/NIFI-7057 > Project: Apache NiFi > Issue Type: Bug >Reporter: Shawn Weeks >Assignee: Makarov Vasiliy Nicolaevich >Priority: Trivial > > The following files need to have their permissions updated for the Docker > profile to run it's tests. I'll add more files if I find them. > chmod 755 ./nifi-toolkit-assembly/docker/tests/exit-codes.sh > chmod 755 ./nifi-toolkit/nifi-toolkit-assembly/docker/tests/tls-toolkit.sh > chmod 755 ./nifi-docker/dockermaven/integration-test.sh > chmod 755 ./nifi-docker/dockermaven/sh/*.sh > chmod 755 ./nifi-docker/dockerhub/sh/*.sh -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (NIFI-7057) Fix Script Permissions For Docker Integration Test
[ https://issues.apache.org/jira/browse/NIFI-7057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17147612#comment-17147612 ] Makarov Vasiliy Nicolaevich commented on NIFI-7057: --- Moving to resolve status. > Fix Script Permissions For Docker Integration Test > -- > > Key: NIFI-7057 > URL: https://issues.apache.org/jira/browse/NIFI-7057 > Project: Apache NiFi > Issue Type: Bug >Reporter: Shawn Weeks >Assignee: Makarov Vasiliy Nicolaevich >Priority: Trivial > > The following files need to have their permissions updated for the Docker > profile to run it's tests. I'll add more files if I find them. > chmod 755 ./nifi-toolkit-assembly/docker/tests/exit-codes.sh > chmod 755 ./nifi-toolkit/nifi-toolkit-assembly/docker/tests/tls-toolkit.sh > chmod 755 ./nifi-docker/dockermaven/integration-test.sh > chmod 755 ./nifi-docker/dockermaven/sh/*.sh > chmod 755 ./nifi-docker/dockerhub/sh/*.sh -- This message was sent by Atlassian Jira (v8.3.4#803005)
