[jira] [Commented] (NIFI-2905) ExecuteProcess should log error stream instead of ignoring it
[ https://issues.apache.org/jira/browse/NIFI-2905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15603869#comment-15603869 ] Koji Kawamura commented on NIFI-2905: - [~JPercivall] Thanks for catching that. I took a look on that and find there is an async call to execute process in another thread and somehow the log was not written, before the main thread to check the log count. I'll investigate more and will send a separate PR to address this. > ExecuteProcess should log error stream instead of ignoring it > - > > Key: NIFI-2905 > URL: https://issues.apache.org/jira/browse/NIFI-2905 > Project: Apache NiFi > Issue Type: Bug >Reporter: Koji Kawamura >Assignee: Koji Kawamura > Fix For: 1.1.0 > > > When a command executed by ExecuteProcess processor didn't work properly and > emitted error messages to error stream, but the processor's configured with > 'Redirect Error Stream' as 'false' (default), then the error messages are > ignored, thus there's no way for user to see what went wrong. > It can provide better UX by logging error stream as WARN level so that user > can see it on bulletin. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2866) The Initial Max Value of QueryDatabaseTable won't be case sensitive.
[ https://issues.apache.org/jira/browse/NIFI-2866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15603779#comment-15603779 ] ASF GitHub Bot commented on NIFI-2866: -- Github user combineads commented on the issue: https://github.com/apache/nifi/pull/1101 @mattyb149 Sorry to bother you again. I changed the commit message. Thanks for your review. > The Initial Max Value of QueryDatabaseTable won't be case sensitive. > > > Key: NIFI-2866 > URL: https://issues.apache.org/jira/browse/NIFI-2866 > Project: Apache NiFi > Issue Type: Bug > Components: Extensions >Affects Versions: 1.1.0 >Reporter: Byunghwa Yun >Priority: Minor > > Now, the Initial Max Value of QueryDatabaseTable is allowed the only > lowercase so I think to change the below code, it added .toLowerCase() method. > for(final Map.EntrymaxProp : > maxValueProperties.entrySet()){ > if > (!statePropertyMap.containsKey(maxProp.getKey().toLowerCase())) { > statePropertyMap.put(maxProp.getKey().toLowerCase(), > maxProp.getValue()); > } > } > When I set the property that is initial.maxvalue.UPDATE_TIME, > QueryDatabaseTable doesn't have WHERE clause with UPDATE_TIME. > Thanks. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] nifi issue #1101: NIFI-2866 The Initial Max Value of QueryDatabaseTable won'...
Github user combineads commented on the issue: https://github.com/apache/nifi/pull/1101 @mattyb149 Sorry to bother you again. I changed the commit message. Thanks for your review. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-2905) ExecuteProcess should log error stream instead of ignoring it
[ https://issues.apache.org/jira/browse/NIFI-2905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15603743#comment-15603743 ] Aldrin Piri commented on NIFI-2905: --- I created a ticket this morning, NIFI-2936 to address. Will link to this issue and you can work it from whichever side makes more sense. > ExecuteProcess should log error stream instead of ignoring it > - > > Key: NIFI-2905 > URL: https://issues.apache.org/jira/browse/NIFI-2905 > Project: Apache NiFi > Issue Type: Bug >Reporter: Koji Kawamura >Assignee: Koji Kawamura > Fix For: 1.1.0 > > > When a command executed by ExecuteProcess processor didn't work properly and > emitted error messages to error stream, but the processor's configured with > 'Redirect Error Stream' as 'false' (default), then the error messages are > ignored, thus there's no way for user to see what went wrong. > It can provide better UX by logging error stream as WARN level so that user > can see it on bulletin. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] nifi issue #1151: [NIFI-2888] Display processor fill color when zoomed in/ou...
Github user mcgilman commented on the issue: https://github.com/apache/nifi/pull/1151 Looks good @scottyaslan. But I think we need to update the Fill Color dialog so the user can see a preview of their color choice with the contrasting color. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-2888) Display processor fill color when sufficiently zoomed out.
[ https://issues.apache.org/jira/browse/NIFI-2888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15603324#comment-15603324 ] ASF GitHub Bot commented on NIFI-2888: -- Github user mcgilman commented on the issue: https://github.com/apache/nifi/pull/1151 Looks good @scottyaslan. But I think we need to update the Fill Color dialog so the user can see a preview of their color choice with the contrasting color. > Display processor fill color when sufficiently zoomed out. > -- > > Key: NIFI-2888 > URL: https://issues.apache.org/jira/browse/NIFI-2888 > Project: Apache NiFi > Issue Type: Improvement > Components: Core UI >Reporter: Scott Aslan >Assignee: Scott Aslan > Fix For: 1.2.0 > > Attachments: processor-change-color.png > > > As a user when viewing the zoomed out overview of my flow I want to be able > to quickly identify processors based on their fill color. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (NIFI-2905) ExecuteProcess should log error stream instead of ignoring it
[ https://issues.apache.org/jira/browse/NIFI-2905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Percivall reopened NIFI-2905: Seeing errors in Travis related to the PR resolving this ticket[1]. Re-opening in order to investigate and address. [1] https://s3.amazonaws.com/archive.travis-ci.org/jobs/170218968/log.txt > ExecuteProcess should log error stream instead of ignoring it > - > > Key: NIFI-2905 > URL: https://issues.apache.org/jira/browse/NIFI-2905 > Project: Apache NiFi > Issue Type: Bug >Reporter: Koji Kawamura >Assignee: Koji Kawamura > Fix For: 1.1.0 > > > When a command executed by ExecuteProcess processor didn't work properly and > emitted error messages to error stream, but the processor's configured with > 'Redirect Error Stream' as 'false' (default), then the error messages are > ignored, thus there's no way for user to see what went wrong. > It can provide better UX by logging error stream as WARN level so that user > can see it on bulletin. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2905) ExecuteProcess should log error stream instead of ignoring it
[ https://issues.apache.org/jira/browse/NIFI-2905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15603252#comment-15603252 ] ASF GitHub Bot commented on NIFI-2905: -- Github user JPercivall commented on the issue: https://github.com/apache/nifi/pull/1143 @ijokarumawak @alopresto @pvillard31 I am seeing errors in travis related to this PR[1]. I am going to re-open the ticket in order to investigate [1] https://s3.amazonaws.com/archive.travis-ci.org/jobs/170218968/log.txt > ExecuteProcess should log error stream instead of ignoring it > - > > Key: NIFI-2905 > URL: https://issues.apache.org/jira/browse/NIFI-2905 > Project: Apache NiFi > Issue Type: Bug >Reporter: Koji Kawamura >Assignee: Koji Kawamura > Fix For: 1.1.0 > > > When a command executed by ExecuteProcess processor didn't work properly and > emitted error messages to error stream, but the processor's configured with > 'Redirect Error Stream' as 'false' (default), then the error messages are > ignored, thus there's no way for user to see what went wrong. > It can provide better UX by logging error stream as WARN level so that user > can see it on bulletin. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] nifi issue #1143: NIFI-2905: Log error stream of ExecuteProcess cmd
Github user JPercivall commented on the issue: https://github.com/apache/nifi/pull/1143 @ijokarumawak @alopresto @pvillard31 I am seeing errors in travis related to this PR[1]. I am going to re-open the ticket in order to investigate [1] https://s3.amazonaws.com/archive.travis-ci.org/jobs/170218968/log.txt --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-2937) In TLS-Toolkit, allow users to specify separate input and output locations for client configuration settings
[ https://issues.apache.org/jira/browse/NIFI-2937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15603242#comment-15603242 ] ASF GitHub Bot commented on NIFI-2937: -- Github user YolandaMDavis commented on the issue: https://github.com/apache/nifi/pull/1158 @brosander will review > In TLS-Toolkit, allow users to specify separate input and output locations > for client configuration settings > > > Key: NIFI-2937 > URL: https://issues.apache.org/jira/browse/NIFI-2937 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 1.0.0 >Reporter: Yolanda M. Davis >Assignee: Bryan Rosander > > Currently when using the tls-toolkit to generate client certificate artifacts > (keystore/truststore etc) users have the option to provide the location of a > configuration file that will provide the information necessary to create > those items (using the "F" argument). Another option can be used to allow > toolkit to write out all of the settings generated back to the indicated > input file (using the "f" argument). For scenarios where users may want to > pipe in input using stdin, vs referring to a file on disk, this is not > optimal since toolkit will attempt to write out to stdin causing an error. > To prevent this error proposing to have the "f" argument also support an > output location, that is separate from the location provided with the "F" > argument. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] nifi issue #1158: NIFI-2937 - Adding configJsonIn option to tls-toolkit clie...
Github user YolandaMDavis commented on the issue: https://github.com/apache/nifi/pull/1158 @brosander will review --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-2937) In TLS-Toolkit, allow users to specify separate input and output locations for client configuration settings
[ https://issues.apache.org/jira/browse/NIFI-2937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15603225#comment-15603225 ] ASF GitHub Bot commented on NIFI-2937: -- GitHub user brosander opened a pull request: https://github.com/apache/nifi/pull/1158 NIFI-2937 - Adding configJsonIn option to tls-toolkit client and server Thank you for submitting a contribution to Apache NiFi. In order to streamline the review of the contribution we ask you to ensure the following steps have been taken: ### For all changes: - [x] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [x] Does your PR title start with NIFI- where is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character. - [x] Has your PR been rebased against the latest commit within the target branch (typically master)? - [x] Is your initial contribution a single, squashed commit? ### For code changes: - [x] Have you ensured that the full suite of tests is executed via mvn -Pcontrib-check clean install at the root nifi folder? - [x] Have you written or updated unit tests to verify your changes? - [x] N/A - If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)? - [x] N/A - If applicable, have you updated the LICENSE file, including the main LICENSE file under nifi-assembly? - [x] N/A - If applicable, have you updated the NOTICE file, including the main NOTICE file found under nifi-assembly? - [x] N/A - If adding new Properties, have you added .displayName in addition to .name (programmatic access) for each of the new properties? ### For documentation related changes: - [x] N/A Have you ensured that format looks appropriate for the output in which it is rendered? ### Note: Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible. You can merge this pull request into a Git repository by running: $ git pull https://github.com/brosander/nifi NIFI-2937 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/1158.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1158 > In TLS-Toolkit, allow users to specify separate input and output locations > for client configuration settings > > > Key: NIFI-2937 > URL: https://issues.apache.org/jira/browse/NIFI-2937 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 1.0.0 >Reporter: Yolanda M. Davis >Assignee: Bryan Rosander > > Currently when using the tls-toolkit to generate client certificate artifacts > (keystore/truststore etc) users have the option to provide the location of a > configuration file that will provide the information necessary to create > those items (using the "F" argument). Another option can be used to allow > toolkit to write out all of the settings generated back to the indicated > input file (using the "f" argument). For scenarios where users may want to > pipe in input using stdin, vs referring to a file on disk, this is not > optimal since toolkit will attempt to write out to stdin causing an error. > To prevent this error proposing to have the "f" argument also support an > output location, that is separate from the location provided with the "F" > argument. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] nifi-minifi pull request #48: MINIFI-60 Removing unused configuration files ...
Github user asfgit closed the pull request at: https://github.com/apache/nifi-minifi/pull/48 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] nifi pull request #1158: NIFI-2937 - Adding configJsonIn option to tls-toolk...
GitHub user brosander opened a pull request: https://github.com/apache/nifi/pull/1158 NIFI-2937 - Adding configJsonIn option to tls-toolkit client and server Thank you for submitting a contribution to Apache NiFi. In order to streamline the review of the contribution we ask you to ensure the following steps have been taken: ### For all changes: - [x] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [x] Does your PR title start with NIFI- where is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character. - [x] Has your PR been rebased against the latest commit within the target branch (typically master)? - [x] Is your initial contribution a single, squashed commit? ### For code changes: - [x] Have you ensured that the full suite of tests is executed via mvn -Pcontrib-check clean install at the root nifi folder? - [x] Have you written or updated unit tests to verify your changes? - [x] N/A - If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)? - [x] N/A - If applicable, have you updated the LICENSE file, including the main LICENSE file under nifi-assembly? - [x] N/A - If applicable, have you updated the NOTICE file, including the main NOTICE file found under nifi-assembly? - [x] N/A - If adding new Properties, have you added .displayName in addition to .name (programmatic access) for each of the new properties? ### For documentation related changes: - [x] N/A Have you ensured that format looks appropriate for the output in which it is rendered? ### Note: Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible. You can merge this pull request into a Git repository by running: $ git pull https://github.com/brosander/nifi NIFI-2937 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/1158.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1158 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-2779) Add processor to GetEmail Supporting Exchange Web Services
[ https://issues.apache.org/jira/browse/NIFI-2779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15603121#comment-15603121 ] Peter Wicks commented on NIFI-2779: --- I have a working prototype, still has a few bugs I've run across, seems to mostly be Text vs HTML emails. I have a working feed, with a Text body and an attachment, going through this processor and then out to an Extract Attachment processor. > Add processor to GetEmail Supporting Exchange Web Services > -- > > Key: NIFI-2779 > URL: https://issues.apache.org/jira/browse/NIFI-2779 > Project: Apache NiFi > Issue Type: New Feature > Components: Core Framework >Affects Versions: 1.0.0 >Reporter: Peter Wicks >Assignee: Peter Wicks >Priority: Minor > > NIFI-1148 added support for POP3/IMAP. > In the comments it was suggested that Exchange Web Services (EWS) support > also be added. > There is a Microsoft created Java API for EWS available in MVN: > https://mvnrepository.com/artifact/com.microsoft.ews-java-api/ews-java-api/2.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2923) Add expression language support to Kerberos parameters used by processors
[ https://issues.apache.org/jira/browse/NIFI-2923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15602992#comment-15602992 ] ASF GitHub Bot commented on NIFI-2923: -- Github user bbende commented on the issue: https://github.com/apache/nifi/pull/1148 Thank you for contributing. In addition to adding the expressionLanguageSupported flag on the property descriptors, we would also need to go through the code and find every place where the properties are evaluated, for example: https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-hadoop-bundle/nifi-hdfs-processors/src/main/java/org/apache/nifi/processors/hadoop/AbstractHadoopProcessor.java#L283 And that would need to call evaluateAttributeExpressions(). > Add expression language support to Kerberos parameters used by processors > - > > Key: NIFI-2923 > URL: https://issues.apache.org/jira/browse/NIFI-2923 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Maurizio Colleluori >Priority: Minor > > Kerberos properties (e.g. principal, keytab) available as attributes in > certain processors (e.g. HDFS processors) only accept a constant value. > Support for expression language could be enabled and allow for > parameterisation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] nifi issue #1148: NIFI-2923 Add expression language support to Kerberos para...
Github user bbende commented on the issue: https://github.com/apache/nifi/pull/1148 Thank you for contributing. In addition to adding the expressionLanguageSupported flag on the property descriptors, we would also need to go through the code and find every place where the properties are evaluated, for example: https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-hadoop-bundle/nifi-hdfs-processors/src/main/java/org/apache/nifi/processors/hadoop/AbstractHadoopProcessor.java#L283 And that would need to call evaluateAttributeExpressions(). --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Assigned] (NIFI-2603) Bringing Some UI Color Back
[ https://issues.apache.org/jira/browse/NIFI-2603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Aslan reassigned NIFI-2603: - Assignee: Scott Aslan (was: Peter Wicks) > Bringing Some UI Color Back > --- > > Key: NIFI-2603 > URL: https://issues.apache.org/jira/browse/NIFI-2603 > Project: Apache NiFi > Issue Type: Improvement > Components: Core UI >Reporter: Peter Wicks >Assignee: Scott Aslan >Priority: Minor > Fix For: 1.1.0 > > Attachments: settings-shell-controller-services.png, > settings-shell-reporting-tasks.png, status-bars-and-components.png, > summary-shell.png > > > In the new 1.0 UI all of the colors associated with status (except the orange > triangle) are gone; replaced with a dark gray color. > I propose bringing back color. The screenshots are in the format of before > on the top and after on the bottom, except were labeled in the picture itself: > - Top Status Menu: https://goo.gl/photos/se1JnvhRwU7N4Fap7 > - Process Group: https://goo.gl/photos/dqjG4KvC6xqxQfgT7 > - Processes (Running/Stopped/Invalid): > https://goo.gl/photos/dSS8vgE2RkrXtc77A > - Operate Play/Stop buttons (only on mouse hover): > https://goo.gl/photos/Am5SUEEn7G9RjmMe6 > - Processor/Processor Group Context Menu: > https://goo.gl/photos/Jq3qFg4ezaN91qms5 > This is not a "100% done, I've covered everything" before/after list. I know > I need to do the NiFi summary page also at the minimum. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2115) Enhanced About Box Version Information
[ https://issues.apache.org/jira/browse/NIFI-2115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15602888#comment-15602888 ] ASF GitHub Bot commented on NIFI-2115: -- Github user jvwing commented on the issue: https://github.com/apache/nifi/pull/583 I pushed another update with changes from feedback: - Removed OS/JVM information from the AboutDTO and About Dialog - Updated the layout of the About Dialog to always show the additional build information, if available - Formatted build timestamp with DateTimeAdapter > Enhanced About Box Version Information > -- > > Key: NIFI-2115 > URL: https://issues.apache.org/jira/browse/NIFI-2115 > Project: Apache NiFi > Issue Type: Improvement > Components: Core UI, Tools and Build >Affects Versions: 1.0.0 >Reporter: James Wing >Assignee: James Wing >Priority: Minor > Attachments: screenshot-1-of-4-about-expands.png, > screenshot-2-of-4-git-build.png, screenshot-3-of-4-release-build.png, > screenshot-4-of-4-source-build.png > > > The UI's About dialog and underlying API provide the version of NiFi, like > "0.7.0-SNAPSHOT". For many bug reports and troubleshooting requests, this is > not very precise, especially around rapidly changing code or > platform-dependent behavior. It would help if NiFi captured and displayed > additional information: > * NiFi build commit hash > * NiFi build branch > * NiFi build date/time > * Java Version > * Java Vendor (Oracle, OpenJDK) > * OS > Then a simple copy/paste from the about box would provide very specific > information about a particular NiFi installation and which code it was > derived from. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] nifi issue #583: NIFI-2115 Detailed Version Info for About Box
Github user jvwing commented on the issue: https://github.com/apache/nifi/pull/583 I pushed another update with changes from feedback: - Removed OS/JVM information from the AboutDTO and About Dialog - Updated the layout of the About Dialog to always show the additional build information, if available - Formatted build timestamp with DateTimeAdapter --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Updated] (NIFI-2791) Create a new Expression Language Function to support Java.lang.Math operations
[ https://issues.apache.org/jira/browse/NIFI-2791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Percivall updated NIFI-2791: --- Status: Patch Available (was: Open) > Create a new Expression Language Function to support Java.lang.Math operations > -- > > Key: NIFI-2791 > URL: https://issues.apache.org/jira/browse/NIFI-2791 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Joseph Percivall >Assignee: Joseph Percivall > Fix For: 1.1.0 > > > Once EL is improved to support decimals (NIFI-1662) it will be desired to > support higher level math functions than are currently implemented. The > easiest way to do this is to provide access to the Math class[1]. This should > provide all the building blocks necessary to do any desired operations on > decimals. > [1] https://docs.oracle.com/javase/7/docs/api/java/lang/Math.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] nifi pull request #1157: NIFI-2791 Adding 'math' expression language functio...
GitHub user JPercivall opened a pull request: https://github.com/apache/nifi/pull/1157 NIFI-2791 Adding 'math' expression language function Thank you for submitting a contribution to Apache NiFi. In order to streamline the review of the contribution we ask you to ensure the following steps have been taken: ### For all changes: - [x] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [x] Does your PR title start with NIFI- where is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character. - [x] Has your PR been rebased against the latest commit within the target branch (typically master)? - [x] Is your initial contribution a single, squashed commit? ### For code changes: - [x] Have you ensured that the full suite of tests is executed via mvn -Pcontrib-check clean install at the root nifi folder? - [x] Have you written or updated unit tests to verify your changes? - [x] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)? - [x] If applicable, have you updated the LICENSE file, including the main LICENSE file under nifi-assembly? - [x] If applicable, have you updated the NOTICE file, including the main NOTICE file found under nifi-assembly? - [x] If adding new Properties, have you added .displayName in addition to .name (programmatic access) for each of the new properties? ### For documentation related changes: - [x] Have you ensured that format looks appropriate for the output in which it is rendered? ### Note: Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible. You can merge this pull request into a Git repository by running: $ git pull https://github.com/JPercivall/nifi NIFI-2791 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/1157.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1157 commit 2c5a4fc193831464862a1a051c3a6b79dc651a9c Author: jpercivallDate: 2016-10-20T14:58:53Z NIFI-2791 Adding 'math' expression language function --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-2791) Create a new Expression Language Function to support Java.lang.Math operations
[ https://issues.apache.org/jira/browse/NIFI-2791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15602877#comment-15602877 ] ASF GitHub Bot commented on NIFI-2791: -- GitHub user JPercivall opened a pull request: https://github.com/apache/nifi/pull/1157 NIFI-2791 Adding 'math' expression language function Thank you for submitting a contribution to Apache NiFi. In order to streamline the review of the contribution we ask you to ensure the following steps have been taken: ### For all changes: - [x] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [x] Does your PR title start with NIFI- where is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character. - [x] Has your PR been rebased against the latest commit within the target branch (typically master)? - [x] Is your initial contribution a single, squashed commit? ### For code changes: - [x] Have you ensured that the full suite of tests is executed via mvn -Pcontrib-check clean install at the root nifi folder? - [x] Have you written or updated unit tests to verify your changes? - [x] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)? - [x] If applicable, have you updated the LICENSE file, including the main LICENSE file under nifi-assembly? - [x] If applicable, have you updated the NOTICE file, including the main NOTICE file found under nifi-assembly? - [x] If adding new Properties, have you added .displayName in addition to .name (programmatic access) for each of the new properties? ### For documentation related changes: - [x] Have you ensured that format looks appropriate for the output in which it is rendered? ### Note: Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible. You can merge this pull request into a Git repository by running: $ git pull https://github.com/JPercivall/nifi NIFI-2791 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/1157.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1157 commit 2c5a4fc193831464862a1a051c3a6b79dc651a9c Author: jpercivallDate: 2016-10-20T14:58:53Z NIFI-2791 Adding 'math' expression language function > Create a new Expression Language Function to support Java.lang.Math operations > -- > > Key: NIFI-2791 > URL: https://issues.apache.org/jira/browse/NIFI-2791 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Joseph Percivall >Assignee: Joseph Percivall > Fix For: 1.1.0 > > > Once EL is improved to support decimals (NIFI-1662) it will be desired to > support higher level math functions than are currently implemented. The > easiest way to do this is to provide access to the Math class[1]. This should > provide all the building blocks necessary to do any desired operations on > decimals. > [1] https://docs.oracle.com/javase/7/docs/api/java/lang/Math.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (NIFI-2937) In TLS-Toolkit, allow users to specify separate input and output locations for client configuration settings
[ https://issues.apache.org/jira/browse/NIFI-2937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Rosander reassigned NIFI-2937: Assignee: Bryan Rosander > In TLS-Toolkit, allow users to specify separate input and output locations > for client configuration settings > > > Key: NIFI-2937 > URL: https://issues.apache.org/jira/browse/NIFI-2937 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 1.0.0 >Reporter: Yolanda M. Davis >Assignee: Bryan Rosander > > Currently when using the tls-toolkit to generate client certificate artifacts > (keystore/truststore etc) users have the option to provide the location of a > configuration file that will provide the information necessary to create > those items (using the "F" argument). Another option can be used to allow > toolkit to write out all of the settings generated back to the indicated > input file (using the "f" argument). For scenarios where users may want to > pipe in input using stdin, vs referring to a file on disk, this is not > optimal since toolkit will attempt to write out to stdin causing an error. > To prevent this error proposing to have the "f" argument also support an > output location, that is separate from the location provided with the "F" > argument. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-318) Web Fonts
[ https://issues.apache.org/jira/browse/NIFI-318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15602810#comment-15602810 ] Matt Gilman commented on NIFI-318: -- We've definitely added infrastructure to address this. Specifically, updating the build to pull down the font's and bundle them in the convenience binaries. This was added due to licensing concerns of bundling some fonts in our source. Off the top of my head, I think we may need to include addition fonts that are used in the documentation and update the docs to use the bundled font. > Web Fonts > - > > Key: NIFI-318 > URL: https://issues.apache.org/jira/browse/NIFI-318 > Project: Apache NiFi > Issue Type: Bug > Components: Core UI >Reporter: Matt Gilman >Priority: Minor > > - Consider using a web font loader for more control when loading fonts from > external sources [1]. Specifically note the iframe support for the NiFi shell > and documents within the help section. > - Update asciidoctor usage to try to eliminate external font (and > font-awesome) dependencies [2][3]. The major issue here is that the Google > fonts API returns a dynamically generated stylesheet based on the browser > requesting the font. This makes for embedding the font's tricky. > [1] https://github.com/typekit/webfontloader > [2] https://github.com/asciidoctor/asciidoctor/issues/879 > [3] > http://mrhaki.blogspot.com/2014/08/awesome-asciidoc-changing-fontawesome.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (NIFI-123) Record reason behind account revocation
[ https://issues.apache.org/jira/browse/NIFI-123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Gilman resolved NIFI-123. -- Resolution: Not A Problem This ticket is OBE. > Record reason behind account revocation > --- > > Key: NIFI-123 > URL: https://issues.apache.org/jira/browse/NIFI-123 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework >Reporter: Matt Gilman >Priority: Minor > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-123) Record reason behind account revocation
[ https://issues.apache.org/jira/browse/NIFI-123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15602802#comment-15602802 ] Matt Gilman commented on NIFI-123: -- This ticket is applicable to the 0.x baseline. For any user account capabilities in 1.x new JIRAs can be created. Thanks. > Record reason behind account revocation > --- > > Key: NIFI-123 > URL: https://issues.apache.org/jira/browse/NIFI-123 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework >Reporter: Matt Gilman >Priority: Minor > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (NIFI-2938) RouteText does not specify the attributes written in its generated docs
[ https://issues.apache.org/jira/browse/NIFI-2938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aldrin Piri updated NIFI-2938: -- Description: RouteText will write the relationship to which a flowfile is directed (RouteText.Route) and, if it was resulting from a matching captured group, would include the RouteText.Group attribute. This is currently not captured in the generated docs for the processor. (was: RouteText will write the relationship to which a flowfile is directed (RouteText.Group) and, if it was resulting from a matching captured group, would include the RouteText.Group attribute. This is currently not captured in the generated docs for the processor.) > RouteText does not specify the attributes written in its generated docs > --- > > Key: NIFI-2938 > URL: https://issues.apache.org/jira/browse/NIFI-2938 > Project: Apache NiFi > Issue Type: Improvement > Components: Documentation & Website, Extensions >Reporter: Aldrin Piri >Priority: Minor > > RouteText will write the relationship to which a flowfile is directed > (RouteText.Route) and, if it was resulting from a matching captured group, > would include the RouteText.Group attribute. This is currently not captured > in the generated docs for the processor. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] nifi pull request #1156: NIFI-2909 and NIFI-1712 Per-Instance ClassLoading
GitHub user bbende opened a pull request: https://github.com/apache/nifi/pull/1156 NIFI-2909 and NIFI-1712 Per-Instance ClassLoading Thank you for submitting a contribution to Apache NiFi. In order to streamline the review of the contribution we ask you to ensure the following steps have been taken: ### For all changes: - [X] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [X] Does your PR title start with NIFI- where is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character. - [X] Has your PR been rebased against the latest commit within the target branch (typically master)? - [X] Is your initial contribution a single, squashed commit? ### For code changes: - [X] Have you ensured that the full suite of tests is executed via mvn -Pcontrib-check clean install at the root nifi folder? - [X] Have you written or updated unit tests to verify your changes? - [ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)? - [ ] If applicable, have you updated the LICENSE file, including the main LICENSE file under nifi-assembly? - [ ] If applicable, have you updated the NOTICE file, including the main NOTICE file found under nifi-assembly? - [ ] If adding new Properties, have you added .displayName in addition to .name (programmatic access) for each of the new properties? ### For documentation related changes: - [ ] Have you ensured that format looks appropriate for the output in which it is rendered? ### Note: Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible. ## Summary of Changes - Introduced a new annotation for processors, reporting tasks, controller services - @RequiresInstanceClassLoading - Added new builder method to PropertyDescriptor dynamicallyModifiesClasspath(boolean) - Created a new InstanceClassLoader that maintains a child-first internal ClassLoader where classpath resources can be set, only used when component has @RequiresInstanceClassLoading - Added support to ExtensionManager to obtain ClassLoaders based on type + id, before we only had by type - If the type being requested supports instance class loading (the annotation described above) it will create an InstanceClassLoader which starts as a copy of the NAR ClassLoader for that type - When properties are set on a component, the framework will identify the properties that are classpath modifiers and add those resources to the InstanceClassLoader's child resources You can merge this pull request into a Git repository by running: $ git pull https://github.com/bbende/nifi NIFI-1712 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/1156.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1156 commit 493a6097d3a44337ab08cfac9b6f8e24b350b2a6 Author: Bryan BendeDate: 2016-10-10T13:27:57Z NIFI-2909 Adding per-instance class loading capability through @RequiresInstanceClassLoading annotation NIFI-1712 Applying per-instance class loading to HBaseClientService to allow specifying Phoenix Client JAR --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Created] (NIFI-2938) RouteText does not specify the attributes written in its generated docs
Aldrin Piri created NIFI-2938: - Summary: RouteText does not specify the attributes written in its generated docs Key: NIFI-2938 URL: https://issues.apache.org/jira/browse/NIFI-2938 Project: Apache NiFi Issue Type: Improvement Components: Documentation & Website, Extensions Reporter: Aldrin Piri Priority: Minor RouteText will write the relationship to which a flowfile is directed (RouteText.Group) and, if it was resulting from a matching captured group, would include the RouteText.Group attribute. This is currently not captured in the generated docs for the processor. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (NIFI-1712) HBaseClientService unable to connect when Phoenix is installed
[ https://issues.apache.org/jira/browse/NIFI-1712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Bende updated NIFI-1712: -- Status: Patch Available (was: In Progress) > HBaseClientService unable to connect when Phoenix is installed > -- > > Key: NIFI-1712 > URL: https://issues.apache.org/jira/browse/NIFI-1712 > Project: Apache NiFi > Issue Type: Bug >Reporter: Bryan Bende >Assignee: Bryan Bende >Priority: Minor > Fix For: 1.1.0 > > > A user reported running HDP 2.3.2 with Phoenix installed, and NiFi 0.6.0, > with the following error: > > 2016-03-31 13:24:23,916 INFO [StandardProcessScheduler Thread-5] > o.a.nifi.hbase.HBase_1_1_2_ClientService > HBase_1_1_2_ClientService[id=e7e9b2ed-d336-34be-acb4-6c8b60c735c2] HBase > Security Enabled, logging in as principal n...@hdp.supergrp.net with keytab > /app/env/nifi.keytab > 2016-03-31 13:24:23,984 WARN [StandardProcessScheduler Thread-5] > org.apache.hadoop.util.NativeCodeLoader Unable to load native-hadoop library > for your platform... using builtin-java classes where applicable > 2016-03-31 13:24:24,101 INFO [StandardProcessScheduler Thread-5] > o.a.nifi.hbase.HBase_1_1_2_ClientService > HBase_1_1_2_ClientService[id=e7e9b2ed-d336-34be-acb4-6c8b60c735c2] > Successfully logged in as principal n...@hdp.supergrp.net with keytab > /app/env/nifi.keytab > 2016-03-31 13:24:24,177 ERROR [StandardProcessScheduler Thread-5] > o.a.n.c.s.StandardControllerServiceNode > HBase_1_1_2_ClientService[id=e7e9b2ed-d336-34be-acb4-6c8b60c735c2] Failed to > invoke @OnEnabled method due to java.io.IOException: > java.lang.reflect.InvocationTargetException > 2016-03-31 13:24:24,182 ERROR [StandardProcessScheduler Thread-5] > o.a.n.c.s.StandardControllerServiceNode > java.io.IOException: java.lang.reflect.InvocationTargetException > at > org.apache.hadoop.hbase.client.ConnectionFactory.createConnection(ConnectionFactory.java:240) > ~[hbase-client-1.1.2.jar:1.1.2] > at > org.apache.hadoop.hbase.client.ConnectionFactory.createConnection(ConnectionFactory.java:218) > ~[hbase-client-1.1.2.jar:1.1.2] > at > org.apache.hadoop.hbase.client.ConnectionFactory.createConnection(ConnectionFactory.java:119) > ~[hbase-client-1.1.2.jar:1.1.2] > at > org.apache.nifi.hbase.HBase_1_1_2_ClientService$1.run(HBase_1_1_2_ClientService.java:215) > ~[nifi-hbase_1_1_2-client-service-0.6.0.jar:0.6.0] > at > org.apache.nifi.hbase.HBase_1_1_2_ClientService$1.run(HBase_1_1_2_ClientService.java:212) > ~[nifi-hbase_1_1_2-client-service-0.6.0.jar:0.6.0] > at java.security.AccessController.doPrivileged(Native Method) > ~[na:1.8.0_71] > at javax.security.auth.Subject.doAs(Subject.java:422) ~[na:1.8.0_71] > at > org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1656) > ~[hadoop-common-2.6.2.jar:na] > at > org.apache.nifi.hbase.HBase_1_1_2_ClientService.createConnection(HBase_1_1_2_ClientService.java:212) > ~[nifi-hbase_1_1_2-client-service-0.6.0.jar:0.6.0] > at > org.apache.nifi.hbase.HBase_1_1_2_ClientService.onEnabled(HBase_1_1_2_ClientService.java:161) > ~[nifi-hbase_1_1_2-client-service-0.6.0.jar:0.6.0] > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > ~[na:1.8.0_71] > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > ~[na:1.8.0_71] > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > ~[na:1.8.0_71] > at java.lang.reflect.Method.invoke(Method.java:497) ~[na:1.8.0_71] > at > org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:137) > ~[na:na] > at > org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:125) > ~[na:na] > at > org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:70) > ~[na:na] > at > org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotation(ReflectionUtils.java:47) > ~[na:na] > at > org.apache.nifi.controller.service.StandardControllerServiceNode$1.run(StandardControllerServiceNode.java:285) > ~[na:na] > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > [na:1.8.0_71] > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > [na:1.8.0_71] > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) > [na:1.8.0_71] > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) > [na:1.8.0_71] > at >
[jira] [Updated] (NIFI-2909) Provide a framework mechanism for loading additional classpath resources
[ https://issues.apache.org/jira/browse/NIFI-2909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Bende updated NIFI-2909: -- Status: Patch Available (was: In Progress) > Provide a framework mechanism for loading additional classpath resources > > > Key: NIFI-2909 > URL: https://issues.apache.org/jira/browse/NIFI-2909 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Bryan Bende >Assignee: Bryan Bende > Fix For: 1.1.0 > > > We currently have several components with a property for specifying > additional classpath resources (DBCP connection pool, scripting processors, > JMS). Each of these components is responsible for handling this in its own > way. > The framework should provide a more integrated solution to make it easier for > component developers to deal with this scenario. Some requirements that need > to be met by this solution: > - Multiple instances of the same component with different resources added to > the classpath and not interfering with each other (i.e. two DBCP connection > pools using different drivers) > - Ability to modify the actual ClassLoader of the component to deal with > frameworks that use Class.forName() without passing in a ClassLoader, meaning > if a processor loads class A and class A calls Class.forName(classBName), > then class B needs to be available in the ClassLoader that loaded the > processor's class which in turn loaded class A > - A component developer should be able to indicate that a given > PropertyDescriptor represents a classpath resource and the framework should > take care of the ClassLoader manipulation -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2909) Provide a framework mechanism for loading additional classpath resources
[ https://issues.apache.org/jira/browse/NIFI-2909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15602762#comment-15602762 ] ASF GitHub Bot commented on NIFI-2909: -- GitHub user bbende opened a pull request: https://github.com/apache/nifi/pull/1156 NIFI-2909 and NIFI-1712 Per-Instance ClassLoading Thank you for submitting a contribution to Apache NiFi. In order to streamline the review of the contribution we ask you to ensure the following steps have been taken: ### For all changes: - [X] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [X] Does your PR title start with NIFI- where is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character. - [X] Has your PR been rebased against the latest commit within the target branch (typically master)? - [X] Is your initial contribution a single, squashed commit? ### For code changes: - [X] Have you ensured that the full suite of tests is executed via mvn -Pcontrib-check clean install at the root nifi folder? - [X] Have you written or updated unit tests to verify your changes? - [ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)? - [ ] If applicable, have you updated the LICENSE file, including the main LICENSE file under nifi-assembly? - [ ] If applicable, have you updated the NOTICE file, including the main NOTICE file found under nifi-assembly? - [ ] If adding new Properties, have you added .displayName in addition to .name (programmatic access) for each of the new properties? ### For documentation related changes: - [ ] Have you ensured that format looks appropriate for the output in which it is rendered? ### Note: Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible. ## Summary of Changes - Introduced a new annotation for processors, reporting tasks, controller services - @RequiresInstanceClassLoading - Added new builder method to PropertyDescriptor dynamicallyModifiesClasspath(boolean) - Created a new InstanceClassLoader that maintains a child-first internal ClassLoader where classpath resources can be set, only used when component has @RequiresInstanceClassLoading - Added support to ExtensionManager to obtain ClassLoaders based on type + id, before we only had by type - If the type being requested supports instance class loading (the annotation described above) it will create an InstanceClassLoader which starts as a copy of the NAR ClassLoader for that type - When properties are set on a component, the framework will identify the properties that are classpath modifiers and add those resources to the InstanceClassLoader's child resources You can merge this pull request into a Git repository by running: $ git pull https://github.com/bbende/nifi NIFI-1712 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/1156.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1156 commit 493a6097d3a44337ab08cfac9b6f8e24b350b2a6 Author: Bryan BendeDate: 2016-10-10T13:27:57Z NIFI-2909 Adding per-instance class loading capability through @RequiresInstanceClassLoading annotation NIFI-1712 Applying per-instance class loading to HBaseClientService to allow specifying Phoenix Client JAR > Provide a framework mechanism for loading additional classpath resources > > > Key: NIFI-2909 > URL: https://issues.apache.org/jira/browse/NIFI-2909 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Bryan Bende >Assignee: Bryan Bende > Fix For: 1.1.0 > > > We currently have several components with a property for specifying > additional classpath resources (DBCP connection pool, scripting processors, > JMS). Each of these components is responsible for handling this in its own > way. > The framework should provide a more integrated solution to make it easier for > component developers to deal with this scenario. Some requirements that need > to be met by this solution: > - Multiple instances of the same component with different resources added to > the classpath and not interfering with each other (i.e. two DBCP connection > pools using different drivers) > - Ability to modify the actual ClassLoader of the component to deal with > frameworks that use
[GitHub] nifi-minifi-cpp pull request #21: MINIFI-124 The active_pid() function kill ...
Github user asfgit closed the pull request at: https://github.com/apache/nifi-minifi-cpp/pull/21 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] nifi-minifi-cpp issue #21: MINIFI-124 The active_pid() function kill -s 0
Github user apiri commented on the issue: https://github.com/apache/nifi-minifi-cpp/pull/21 Looks good here and thanks for catching! Will merge. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] nifi-minifi-cpp issue #21: MINIFI-124 The active_pid() function kill -s 0
Github user apiri commented on the issue: https://github.com/apache/nifi-minifi-cpp/pull/21 reviewing --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-2888) Display processor fill color when sufficiently zoomed out.
[ https://issues.apache.org/jira/browse/NIFI-2888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15602553#comment-15602553 ] ASF GitHub Bot commented on NIFI-2888: -- Github user mcgilman commented on a diff in the pull request: https://github.com/apache/nifi/pull/1151#discussion_r84731755 --- Diff: nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-ui/src/main/webapp/js/nf/canvas/nf-processor.js --- @@ -547,30 +557,64 @@ nf.Processor = (function () { details.remove(); } } -}); - -// --- -// processor color -// --- - -// update the processor color -updated.select('text.processor-icon') -.style('fill', function (d) { - -// get the default color -var color = nf.Processor.defaultColor(); - -if (!d.permissions.canRead) { -return color; -} -// use the specified color if appropriate -if (nf.Common.isDefinedAndNotNull(d.component.style['background-color'])) { -color = d.component.style['background-color']; -} +// --- +// processor color +// --- -return color; -}); +// update the processor color +processor.select('text.processor-icon') +.style('fill', function (d) { + +// get the default color +var color = nf.Processor.defaultColor(); + +if (!d.permissions.canRead) { +//update the processor icon container + processor.select('rect.processor-icon-container').classed('unauthorized', true); --- End diff -- I don't think we should be updating/modifying these elements within the callback for a different element. Because we're already iterating through each matched processor, `d` is already available as `processorData`. Each of these` processor.select` should be brought outside of this callback. FYI - we're using `.each` in this case because of how the tooltips are implemented. They didn't directly map into the traditional mapping process. > Display processor fill color when sufficiently zoomed out. > -- > > Key: NIFI-2888 > URL: https://issues.apache.org/jira/browse/NIFI-2888 > Project: Apache NiFi > Issue Type: Improvement > Components: Core UI >Reporter: Scott Aslan >Assignee: Scott Aslan > Fix For: 1.2.0 > > Attachments: processor-change-color.png > > > As a user when viewing the zoomed out overview of my flow I want to be able > to quickly identify processors based on their fill color. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2603) Bringing Some UI Color Back
[ https://issues.apache.org/jira/browse/NIFI-2603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15602323#comment-15602323 ] Peter Wicks commented on NIFI-2603: --- I would have no issues, and greatly appreciate, you taking this on :) I want to work on it, but I find myself working on other more pressing issues that I actually need for day-to-day flow construction. > Bringing Some UI Color Back > --- > > Key: NIFI-2603 > URL: https://issues.apache.org/jira/browse/NIFI-2603 > Project: Apache NiFi > Issue Type: Improvement > Components: Core UI >Reporter: Peter Wicks >Assignee: Peter Wicks >Priority: Minor > Fix For: 1.1.0 > > Attachments: settings-shell-controller-services.png, > settings-shell-reporting-tasks.png, status-bars-and-components.png, > summary-shell.png > > > In the new 1.0 UI all of the colors associated with status (except the orange > triangle) are gone; replaced with a dark gray color. > I propose bringing back color. The screenshots are in the format of before > on the top and after on the bottom, except were labeled in the picture itself: > - Top Status Menu: https://goo.gl/photos/se1JnvhRwU7N4Fap7 > - Process Group: https://goo.gl/photos/dqjG4KvC6xqxQfgT7 > - Processes (Running/Stopped/Invalid): > https://goo.gl/photos/dSS8vgE2RkrXtc77A > - Operate Play/Stop buttons (only on mouse hover): > https://goo.gl/photos/Am5SUEEn7G9RjmMe6 > - Processor/Processor Group Context Menu: > https://goo.gl/photos/Jq3qFg4ezaN91qms5 > This is not a "100% done, I've covered everything" before/after list. I know > I need to do the NiFi summary page also at the minimum. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] nifi issue #1101: NIFI-2866 The Initial Max Value of QueryDatabaseTable won'...
Github user mattyb149 commented on the issue: https://github.com/apache/nifi/pull/1101 Looking good, I will give this a try. However the commit that updated the unit test seems to have a title that came from a different PR/Jira case, do you mind changing the name of the commit to be more indicative of the change that was made? Thanks for the contribution! --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Assigned] (NIFI-2926) Add a user-centric view for authorization policies
[ https://issues.apache.org/jira/browse/NIFI-2926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Aslan reassigned NIFI-2926: - Assignee: Scott Aslan > Add a user-centric view for authorization policies > -- > > Key: NIFI-2926 > URL: https://issues.apache.org/jira/browse/NIFI-2926 > Project: Apache NiFi > Issue Type: Improvement > Components: Core UI >Affects Versions: 1.0.0 >Reporter: Andrew Lim >Assignee: Scott Aslan > Labels: UI, authorization > > The UI for managing authorizations in 1.0.0 is policy-centric, meaning in > order to view which access privileges a specific user has, you need to > navigate to each individual policy and see if the user has been added to it. > We should add a view to the UI where you can select a user and then see all > the access policies that he/she has. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (NIFI-1069) Nifi Service Status return 0 when service not running
[ https://issues.apache.org/jira/browse/NIFI-1069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Percivall reopened NIFI-1069: Re-opening because I believe this commit broke "restart" functionality of nifi.sh. I tried it on the previous commit on master[1] and it works but when I tested this commit it failed. It stops the instance but doesn't initiate a restart. [1] https://github.com/apache/nifi/commit/231f5143ab8100d6a5d4543a5476694378fdcf6d > Nifi Service Status return 0 when service not running > - > > Key: NIFI-1069 > URL: https://issues.apache.org/jira/browse/NIFI-1069 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 0.3.0 > Environment: CentOS 6.7 >Reporter: Andy Kruth >Assignee: Andre >Priority: Minor > Fix For: 1.1.0 > > > After successfully installing Nifi as a service with the following command: > sudo /opt/nifi-0.3.0/bin/nifi.sh install > running service nifi status has a return code of 0. > According to > http://refspecs.linuxbase.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html > if the service is not running then status should return 3. > This is not a major issue, you can still start and stop the service just > fine, but when using an idempotent tool like Ansible you cannot start the > service because the return code of status says the service is already started. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-1069) Nifi Service Status return 0 when service not running
[ https://issues.apache.org/jira/browse/NIFI-1069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15602262#comment-15602262 ] ASF GitHub Bot commented on NIFI-1069: -- Github user JPercivall commented on the issue: https://github.com/apache/nifi/pull/1093 @michalklempa @trixpan I believe this commit broke "restart" functionality of nifi.sh. I tried it on the previous commit on master[1] and it works but when I tested this commit it failed. It stops the instance but doesn't initiate a restart. [1] https://github.com/apache/nifi/commit/231f5143ab8100d6a5d4543a5476694378fdcf6d > Nifi Service Status return 0 when service not running > - > > Key: NIFI-1069 > URL: https://issues.apache.org/jira/browse/NIFI-1069 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 0.3.0 > Environment: CentOS 6.7 >Reporter: Andy Kruth >Assignee: Andre >Priority: Minor > Fix For: 1.1.0 > > > After successfully installing Nifi as a service with the following command: > sudo /opt/nifi-0.3.0/bin/nifi.sh install > running service nifi status has a return code of 0. > According to > http://refspecs.linuxbase.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html > if the service is not running then status should return 3. > This is not a major issue, you can still start and stop the service just > fine, but when using an idempotent tool like Ansible you cannot start the > service because the return code of status says the service is already started. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] nifi issue #1093: Fixes NIFI-1069 init script status exit code 3 when not ru...
Github user JPercivall commented on the issue: https://github.com/apache/nifi/pull/1093 @michalklempa @trixpan I believe this commit broke "restart" functionality of nifi.sh. I tried it on the previous commit on master[1] and it works but when I tested this commit it failed. It stops the instance but doesn't initiate a restart. [1] https://github.com/apache/nifi/commit/231f5143ab8100d6a5d4543a5476694378fdcf6d --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-2603) Bringing Some UI Color Back
[ https://issues.apache.org/jira/browse/NIFI-2603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15602253#comment-15602253 ] Scott Aslan commented on NIFI-2603: --- [~patricker], how is your progress coming along? I have some bandwidth coming available and I could offer my assistance on this if you like? Also, I think the community really would like to see this effort completed for the upcoming 1.1.0 so FYI I have updated the fix version... > Bringing Some UI Color Back > --- > > Key: NIFI-2603 > URL: https://issues.apache.org/jira/browse/NIFI-2603 > Project: Apache NiFi > Issue Type: Improvement > Components: Core UI >Reporter: Peter Wicks >Assignee: Peter Wicks >Priority: Minor > Fix For: 1.1.0 > > Attachments: settings-shell-controller-services.png, > settings-shell-reporting-tasks.png, status-bars-and-components.png, > summary-shell.png > > > In the new 1.0 UI all of the colors associated with status (except the orange > triangle) are gone; replaced with a dark gray color. > I propose bringing back color. The screenshots are in the format of before > on the top and after on the bottom, except were labeled in the picture itself: > - Top Status Menu: https://goo.gl/photos/se1JnvhRwU7N4Fap7 > - Process Group: https://goo.gl/photos/dqjG4KvC6xqxQfgT7 > - Processes (Running/Stopped/Invalid): > https://goo.gl/photos/dSS8vgE2RkrXtc77A > - Operate Play/Stop buttons (only on mouse hover): > https://goo.gl/photos/Am5SUEEn7G9RjmMe6 > - Processor/Processor Group Context Menu: > https://goo.gl/photos/Jq3qFg4ezaN91qms5 > This is not a "100% done, I've covered everything" before/after list. I know > I need to do the NiFi summary page also at the minimum. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (NIFI-2603) Bringing Some UI Color Back
[ https://issues.apache.org/jira/browse/NIFI-2603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Aslan updated NIFI-2603: -- Fix Version/s: 1.1.0 > Bringing Some UI Color Back > --- > > Key: NIFI-2603 > URL: https://issues.apache.org/jira/browse/NIFI-2603 > Project: Apache NiFi > Issue Type: Improvement > Components: Core UI >Reporter: Peter Wicks >Assignee: Peter Wicks >Priority: Minor > Fix For: 1.1.0 > > Attachments: settings-shell-controller-services.png, > settings-shell-reporting-tasks.png, status-bars-and-components.png, > summary-shell.png > > > In the new 1.0 UI all of the colors associated with status (except the orange > triangle) are gone; replaced with a dark gray color. > I propose bringing back color. The screenshots are in the format of before > on the top and after on the bottom, except were labeled in the picture itself: > - Top Status Menu: https://goo.gl/photos/se1JnvhRwU7N4Fap7 > - Process Group: https://goo.gl/photos/dqjG4KvC6xqxQfgT7 > - Processes (Running/Stopped/Invalid): > https://goo.gl/photos/dSS8vgE2RkrXtc77A > - Operate Play/Stop buttons (only on mouse hover): > https://goo.gl/photos/Am5SUEEn7G9RjmMe6 > - Processor/Processor Group Context Menu: > https://goo.gl/photos/Jq3qFg4ezaN91qms5 > This is not a "100% done, I've covered everything" before/after list. I know > I need to do the NiFi summary page also at the minimum. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (NIFI-2936) TestExecuteProcess errors in Travis CI environment
Aldrin Piri created NIFI-2936: - Summary: TestExecuteProcess errors in Travis CI environment Key: NIFI-2936 URL: https://issues.apache.org/jira/browse/NIFI-2936 Project: Apache NiFi Issue Type: Improvement Components: Tools and Build Reporter: Aldrin Piri Priority: Minor The introduction of redirecting error stream and the accompanying tests for TestExecuteProcess [1] are causing Travis to have issues with the build fairly consistently starting with the initial travis build #4109 [2]. [1] https://github.com/apache/nifi/commit/27dba60f27579ca9f33aa1afbf4bb46182d57df4 [2] https://travis-ci.org/apache/nifi/builds/168776478 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] nifi-minifi pull request #48: MINIFI-60 Removing unused configuration files ...
GitHub user apiri opened a pull request: https://github.com/apache/nifi-minifi/pull/48 MINIFI-60 Removing unused configuration files in minifi-resources. Thank you for submitting a contribution to Apache NiFi - MiNiFi. In order to streamline the review of the contribution we ask you to ensure the following steps have been taken: ### For all changes: - [X ] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [ x] Does your PR title start with MINIFI- where is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character. - [x ] Has your PR been rebased against the latest commit within the target branch (typically master)? - [x ] Is your initial contribution a single, squashed commit? ### For code changes: - [x ] Have you ensured that the full suite of tests is executed via mvn -Pcontrib-check clean install at the root nifi-minifi folder? - [ ] Have you written or updated unit tests to verify your changes? - [ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)? - [ ] If applicable, have you updated the LICENSE file, including the main LICENSE file under minifi-assembly? - [ ] If applicable, have you updated the NOTICE file, including the main NOTICE file found under minifi-assembly? ### For documentation related changes: - [ ] Have you ensured that format looks appropriate for the output in which it is rendered? ### Note: Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible. You can merge this pull request into a Git repository by running: $ git pull https://github.com/apiri/nifi-minifi MINIFI-60 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi-minifi/pull/48.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #48 commit e4d91c8d5c55e2501a32ca83a4b5d581e736e248 Author: Aldrin PiriDate: 2016-10-24T14:32:08Z MINIFI-60 Removing unused configuration files in minifi-resources. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Updated] (NIFI-2935) GetAzureEventHub freezes after period of reading data
[ https://issues.apache.org/jira/browse/NIFI-2935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michiel Moonen updated NIFI-2935: - Attachment: nifi logs.zip Attached the nifi logs, including screenshots of history trends. - Looking at the screen captures, the task duration trend suggests perhaps a memory leak? - In nifi-app_2016-10-24_12.0.log around 12:07 there's an exception (nullpointer). > GetAzureEventHub freezes after period of reading data > - > > Key: NIFI-2935 > URL: https://issues.apache.org/jira/browse/NIFI-2935 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.0.0, 0.7.0 >Reporter: Michiel Moonen > Attachments: nifi logs.zip > > > We have a GetAzureEventHub processor running on a AWS instance to collect > data from Azure. Runs quite smoothly, no heavy load (~140 kb / 30 seconds), > but after 2 - 14 hours it just stops collecting data. > GetAzureEventHub Processor block can be stopped in UI, but 'under the hood' > actually it doesn't stop; processor block actually freezes / no response. > Only option is to kill NiFi (which eventually terminates itself forcefully). > Feels like some buffer has been flooded. > I don't have logs atm, will add them soon. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2928) FetchFile routes to not.found when it cannot determine whether or not the file exists
[ https://issues.apache.org/jira/browse/NIFI-2928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15602168#comment-15602168 ] Oleg Zhurakousky commented on NIFI-2928: [~ch...@mcdermott.net] after reading javadoc for _checkAccess()_ I am now starting to think that it is good the way it is now. Basically here is what it says: {code} * Checks the existence, and optionally the accessibility, of a file. . . . * This method checks the existence of a file and that this Java virtual * machine has appropriate privileges that would allow it access the file * according to all of access modes specified in the {@code modes} parameter * as follows: . . . {code} Basically while one may argue that this method is a bit more sophisticated then what we have now, in reality there is no way to distinguish between non-existing file or non-accessible file since it encapsulates both/all. Do you agree? > FetchFile routes to not.found when it cannot determine whether or not the > file exists > - > > Key: NIFI-2928 > URL: https://issues.apache.org/jira/browse/NIFI-2928 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 0.7.1 >Reporter: Christopher McDermott >Assignee: Oleg Zhurakousky > Fix For: 1.1.0 > > > I have a flow that reads files from an NFS volume. To simulate the NFS > server being offline/unreachable I am using IP tables to block all TCP > traffic between the NFS server and the host running NiFi. > Trying to read files using FetchFile, I am seeing > 2016-10-20 20:34:31,789 ERROR [Timer-Driven Process Thread-4] > o.a.nifi.processors.standard.FetchFile > FetchFile[id=9e642524-0e05-4d58-aabc-d6b49d687917] Could not fetch file > /share/st5103/REDACTED from file system for > StandardFlowFileRecord[uuid=1f88f322-57a2-4ac5-87df-d53fdd63d52c,claim=StandardContentClaim > [resourceClaim=StandardResourceClaim[id=1476995181657-18524, > container=default, section=92], offset=569544, > length=745],offset=0,name=1248995905448067,size=745] because the file does > not exist; routing to not.found > The file is actually there, but of course it is inaccessible because the > network traffic is blocked. > I see the code is using {{File.exists()}}. > This [bug|https://bugs.openjdk.java.net/browse/JDK-6191254] report suggest > that it should instead use > {{[File.toPath().checkAccess()|http://download.java.net/jdk7/archive/b123/docs/api/java/nio/file/Path.html#checkAccess(java.nio.file.AccessMode...)]}} > {{[java.nio.Files.notExists()|http://docs.oracle.com/javase/7docs/api/java/nio/file/Files.html#notExists-java.nio.file.Path-java.nio.file.LinkOption...-]}} > uses {{checkAccess()}} and might be a drop-in replacement. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] nifi pull request #1018: NIFI-1662 adding Expression Language decimal suppor...
Github user asfgit closed the pull request at: https://github.com/apache/nifi/pull/1018 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-1662) Improve Expression Language to Enable Working with Decimals
[ https://issues.apache.org/jira/browse/NIFI-1662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15602162#comment-15602162 ] ASF subversion and git services commented on NIFI-1662: --- Commit 557e0b9f27fe8fd99aa0ac6feda597ea26fc3357 in nifi's branch refs/heads/master from [~mattyb149] [ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=557e0b9 ] NIFI-1662: Added support for decimal literal in Expression Language > Improve Expression Language to Enable Working with Decimals > --- > > Key: NIFI-1662 > URL: https://issues.apache.org/jira/browse/NIFI-1662 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Joseph Percivall >Assignee: Joseph Percivall > Fix For: 1.1.0 > > > Currently the math operations in Expression Language use Longs to evaluate > numbers. This leads to any decimal places getting truncated when performing > operations like divide. > NiFi should support working with decimals -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (NIFI-1662) Improve Expression Language to Enable Working with Decimals
[ https://issues.apache.org/jira/browse/NIFI-1662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Burgess updated NIFI-1662: --- Resolution: Fixed Status: Resolved (was: Patch Available) > Improve Expression Language to Enable Working with Decimals > --- > > Key: NIFI-1662 > URL: https://issues.apache.org/jira/browse/NIFI-1662 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Joseph Percivall >Assignee: Joseph Percivall > Fix For: 1.1.0 > > > Currently the math operations in Expression Language use Longs to evaluate > numbers. This leads to any decimal places getting truncated when performing > operations like divide. > NiFi should support working with decimals -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-1662) Improve Expression Language to Enable Working with Decimals
[ https://issues.apache.org/jira/browse/NIFI-1662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15602163#comment-15602163 ] ASF subversion and git services commented on NIFI-1662: --- Commit e4a3e096432f43087c499d69bcbb4f2a013269a7 in nifi's branch refs/heads/master from [~JPercivall] [ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=e4a3e09 ] NIFI-1662 Adding proper UI regex support for decimals in EL This closes #1018 > Improve Expression Language to Enable Working with Decimals > --- > > Key: NIFI-1662 > URL: https://issues.apache.org/jira/browse/NIFI-1662 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Joseph Percivall >Assignee: Joseph Percivall > Fix For: 1.1.0 > > > Currently the math operations in Expression Language use Longs to evaluate > numbers. This leads to any decimal places getting truncated when performing > operations like divide. > NiFi should support working with decimals -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-1662) Improve Expression Language to Enable Working with Decimals
[ https://issues.apache.org/jira/browse/NIFI-1662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15602161#comment-15602161 ] ASF subversion and git services commented on NIFI-1662: --- Commit 94ab99902602d20d53a63ac86bed7c99cf06c9c9 in nifi's branch refs/heads/master from [~JPercivall] [ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=94ab999 ] NIFI-1662 adding Expression Language decimal support > Improve Expression Language to Enable Working with Decimals > --- > > Key: NIFI-1662 > URL: https://issues.apache.org/jira/browse/NIFI-1662 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Joseph Percivall >Assignee: Joseph Percivall > Fix For: 1.1.0 > > > Currently the math operations in Expression Language use Longs to evaluate > numbers. This leads to any decimal places getting truncated when performing > operations like divide. > NiFi should support working with decimals -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (NIFI-2533) When searching for users to add to a policy, should filter out users that are already on the policy
[ https://issues.apache.org/jira/browse/NIFI-2533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Gilman updated NIFI-2533: -- Fix Version/s: 1.1.0 Status: Patch Available (was: In Progress) https://github.com/apache/nifi/pull/1155 > When searching for users to add to a policy, should filter out users that are > already on the policy > --- > > Key: NIFI-2533 > URL: https://issues.apache.org/jira/browse/NIFI-2533 > Project: Apache NiFi > Issue Type: Improvement > Components: Core UI >Affects Versions: 1.0.0 >Reporter: Andrew Lim >Assignee: Matt Gilman >Priority: Minor > Fix For: 1.1.0 > > Attachments: NIFI-2533.png > > > As shown in the attached screenshot. User1 is already on the policy. When > adding additional users to the policy, the "Search users" window should > filter out User1 from the list. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (NIFI-2935) GetAzureEventHub freezes after period of reading data
[ https://issues.apache.org/jira/browse/NIFI-2935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michiel Moonen updated NIFI-2935: - Summary: GetAzureEventHub freezes after period of reading data (was: GetAzureEventHub freezes after certain period of reading data) > GetAzureEventHub freezes after period of reading data > - > > Key: NIFI-2935 > URL: https://issues.apache.org/jira/browse/NIFI-2935 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.0.0, 0.7.0 >Reporter: Michiel Moonen > > We have a GetAzureEventHub processor running on a AWS instance to collect > data from Azure. Runs quite smoothly, no heavy load (~140 kb / 30 seconds), > but after 2 - 14 hours it just stops collecting data. > GetAzureEventHub Processor block can be stopped in UI, but 'under the hood' > actually it doesn't stop; processor block actually freezes / no response. > Only option is to kill NiFi (which eventually terminates itself forcefully). > Feels like some buffer has been flooded. > I don't have logs atm, will add them soon. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (NIFI-2286) Policies: "Add user to policy" and "Remove" icons do not have hover help text
[ https://issues.apache.org/jira/browse/NIFI-2286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Gilman updated NIFI-2286: -- Fix Version/s: 1.1.0 Status: Patch Available (was: In Progress) https://github.com/apache/nifi/pull/1155 > Policies: "Add user to policy" and "Remove" icons do not have hover help text > -- > > Key: NIFI-2286 > URL: https://issues.apache.org/jira/browse/NIFI-2286 > Project: Apache NiFi > Issue Type: Improvement > Components: Core UI >Affects Versions: 1.0.0 >Reporter: Andrew Lim >Assignee: Matt Gilman >Priority: Minor > Labels: UI > Fix For: 1.1.0 > > > The "Add user to policy" and "Remove" buttons in the Access Policies window > do not have any help text displayed when the user hovers over them. > This will be really helpful especially to new users of the Authorization API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (NIFI-2884) UI - Support bulk user/group add when editing a policy
[ https://issues.apache.org/jira/browse/NIFI-2884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Gilman updated NIFI-2884: -- Fix Version/s: (was: 1.2.0) 1.1.0 Status: Patch Available (was: In Progress) https://github.com/apache/nifi/pull/1155 > UI - Support bulk user/group add when editing a policy > -- > > Key: NIFI-2884 > URL: https://issues.apache.org/jira/browse/NIFI-2884 > Project: Apache NiFi > Issue Type: Improvement > Components: Core UI >Reporter: Matt Gilman >Assignee: Matt Gilman > Fix For: 1.1.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2884) UI - Support bulk user/group add when editing a policy
[ https://issues.apache.org/jira/browse/NIFI-2884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15602148#comment-15602148 ] ASF GitHub Bot commented on NIFI-2884: -- GitHub user mcgilman opened a pull request: https://github.com/apache/nifi/pull/1155 Edit Policy - Bulk user/group add NIFI-2884: - Adding support to selecting multiple users before updating a policy. NIFI-2533: - Only including a user/group in the search results if they are not currently selected. NIFI-2286: - Providing a tooltip for the add user and remove policy button. You can merge this pull request into a Git repository by running: $ git pull https://github.com/mcgilman/nifi NIFI-2884 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/1155.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1155 commit b1f27d941bf2a8b06a79a764ae7c5aeb098c63c9 Author: Matt GilmanDate: 2016-10-24T14:28:17Z NIFI-2884: - Adding support to selecting multiple users before updating a policy. NIFI-2533: - Only including a user/group in the search results if they are not currently selected. NIFI-2286: - Providing a tooltip for the add user and remove policy button. > UI - Support bulk user/group add when editing a policy > -- > > Key: NIFI-2884 > URL: https://issues.apache.org/jira/browse/NIFI-2884 > Project: Apache NiFi > Issue Type: Improvement > Components: Core UI >Reporter: Matt Gilman >Assignee: Matt Gilman > Fix For: 1.1.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] nifi pull request #1155: Edit Policy - Bulk user/group add
GitHub user mcgilman opened a pull request: https://github.com/apache/nifi/pull/1155 Edit Policy - Bulk user/group add NIFI-2884: - Adding support to selecting multiple users before updating a policy. NIFI-2533: - Only including a user/group in the search results if they are not currently selected. NIFI-2286: - Providing a tooltip for the add user and remove policy button. You can merge this pull request into a Git repository by running: $ git pull https://github.com/mcgilman/nifi NIFI-2884 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/1155.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1155 commit b1f27d941bf2a8b06a79a764ae7c5aeb098c63c9 Author: Matt GilmanDate: 2016-10-24T14:28:17Z NIFI-2884: - Adding support to selecting multiple users before updating a policy. NIFI-2533: - Only including a user/group in the search results if they are not currently selected. NIFI-2286: - Providing a tooltip for the add user and remove policy button. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-1662) Improve Expression Language to Enable Working with Decimals
[ https://issues.apache.org/jira/browse/NIFI-1662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15602126#comment-15602126 ] ASF GitHub Bot commented on NIFI-1662: -- Github user mattyb149 commented on the issue: https://github.com/apache/nifi/pull/1018 +1 LGTM, great addition here, thanks! Merging to master > Improve Expression Language to Enable Working with Decimals > --- > > Key: NIFI-1662 > URL: https://issues.apache.org/jira/browse/NIFI-1662 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Joseph Percivall >Assignee: Joseph Percivall > Fix For: 1.1.0 > > > Currently the math operations in Expression Language use Longs to evaluate > numbers. This leads to any decimal places getting truncated when performing > operations like divide. > NiFi should support working with decimals -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] nifi issue #1018: NIFI-1662 adding Expression Language decimal support
Github user mattyb149 commented on the issue: https://github.com/apache/nifi/pull/1018 +1 LGTM, great addition here, thanks! Merging to master --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Assigned] (NIFI-2340) Incremental database processors should support incoming flow files and Expression Language
[ https://issues.apache.org/jira/browse/NIFI-2340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Burgess reassigned NIFI-2340: -- Assignee: Matt Burgess > Incremental database processors should support incoming flow files and > Expression Language > -- > > Key: NIFI-2340 > URL: https://issues.apache.org/jira/browse/NIFI-2340 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 1.0.0, 0.7.0 >Reporter: Matt Burgess >Assignee: Matt Burgess > > QueryDatabaseTable and GenerateTableFetch do not support incoming > connections, which makes them less flexible for accepting table names, such > as using Expression Language (EL) for names located in flow file attributes, > e.g.) The use of EL (to include custom properties and the Variable Registry) > will enable these processors to fetch arbitrary tables based on the provided > values. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-1531) fix .gitignores throughout codebase
[ https://issues.apache.org/jira/browse/NIFI-1531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15602037#comment-15602037 ] ASF subversion and git services commented on NIFI-1531: --- Commit 05d5fbad65cbc527e6f45b85c25fffe3f2905932 in nifi's branch refs/heads/0.x from Andre F de Miranda [ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=05d5fba ] NIFI-1531 - Remove bogus .gitignore files from sub directories This closes #1154. Signed-off-by: Aldrin Piri> fix .gitignores throughout codebase > --- > > Key: NIFI-1531 > URL: https://issues.apache.org/jira/browse/NIFI-1531 > Project: Apache NiFi > Issue Type: Task > Components: Tools and Build >Reporter: Tony Kurc >Assignee: Andre > Fix For: 1.1.0, 0.8.0 > > > There are some unnecessary and incorrect > (https://github.com/apache/nifi/blob/master/nifi-commons/nifi-properties/.gitignore) > .gitignore files. These should be cleaned up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (NIFI-1531) fix .gitignores throughout codebase
[ https://issues.apache.org/jira/browse/NIFI-1531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aldrin Piri updated NIFI-1531: -- Fix Version/s: 0.8.0 1.1.0 > fix .gitignores throughout codebase > --- > > Key: NIFI-1531 > URL: https://issues.apache.org/jira/browse/NIFI-1531 > Project: Apache NiFi > Issue Type: Task > Components: Tools and Build >Reporter: Tony Kurc >Assignee: Andre > Fix For: 1.1.0, 0.8.0 > > > There are some unnecessary and incorrect > (https://github.com/apache/nifi/blob/master/nifi-commons/nifi-properties/.gitignore) > .gitignore files. These should be cleaned up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2934) Archiver still not respecting nifi.content.repository.archive.max.usage.percentage
[ https://issues.apache.org/jira/browse/NIFI-2934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15602005#comment-15602005 ] Joseph Gresock commented on NIFI-2934: -- Do you mean flow file swapping in NiFi? If so, what should I look for in the logs to find that? I'll send over the lsof output next time it happens. > Archiver still not respecting > nifi.content.repository.archive.max.usage.percentage > -- > > Key: NIFI-2934 > URL: https://issues.apache.org/jira/browse/NIFI-2934 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 0.7.0, 0.7.1 >Reporter: Joseph Gresock > Attachments: Disk-Usage-Increasing.png, NiFi-80-percent-disk.png, > Queued.png, System-Diagnostics.png, content_repository usage.png > > > This seems related to NIFI-1726: we've noticed that the content repository > takes up increasingly more space over time, even beyond the configured max > usage percentage (see images). After restarting the NiFi cluster we get an > immediate drop in disk usage with lots of log statements indicating that > expired content is being removed. > Not sure if this is related, but we also often get "Too many open files" > during this expiration process after NiFi restart, despite lsof indicating a > count far lower than our configured nofile and fs-max. > In the environment indicated by the pictures, > nifi.content.repository.archive.max.usage.percentage = 50%. Note that the > flow itself only has ~240GB queued across the entire cluster, but each > content_repository directory has over 360GB on each worker. Also note the > disk usage graph increasing above 50% on each worker, until we finally > restart and then the usage drops below 50%. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2925) FlowFiles that are swapped out are never released from Content Repository
[ https://issues.apache.org/jira/browse/NIFI-2925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15601969#comment-15601969 ] ASF GitHub Bot commented on NIFI-2925: -- Github user bbende commented on the issue: https://github.com/apache/nifi/pull/1150 Reviewing... > FlowFiles that are swapped out are never released from Content Repository > - > > Key: NIFI-2925 > URL: https://issues.apache.org/jira/browse/NIFI-2925 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.0.0 >Reporter: Mark Payne >Assignee: Mark Payne >Priority: Blocker > Fix For: 1.1.0 > > > To reproduce this, I created a simple Flow: GenerateFlowFile (1 KB file size) > with success going to 2 different UpdateAttribute Processors (so that the > same Content Claim is held by 2 different FlowFiles). I let about 150,000 > FlowFiles queue up (with backpressure turned off). I then start one of the > UpdateAttribute processors. This drained its queue. I could then look at my > content repo for any files not archived: > {code} > content_repository $ find . -type f | grep -v archive | wc -l > 192 > {code} > After a few minutes, the FlowFile repo is checkpointed, which will result in > things getting cleaned up if they can. The above command shows the same > result (expected, since the FlowFiles are still held. I then empty the queue. > After the FlowFile checkpoints again, I should see nothing in the content > repo outside of archive, but I see: > {code} > content_repository $ find . -type f | grep -v archive | wc -l > 167 > {code} > I see the same thing happening if I turn on expiration to remove the > FlowFiles instead of clicking Empty Queue, or if a processor runs and > completes the processing of the data. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] nifi issue #1150: NIFI-2925: When swapping in FlowFiles, do not assume that ...
Github user bbende commented on the issue: https://github.com/apache/nifi/pull/1150 Reviewing... --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-2934) Archiver still not respecting nifi.content.repository.archive.max.usage.percentage
[ https://issues.apache.org/jira/browse/NIFI-2934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15601900#comment-15601900 ] Joseph Witt commented on NIFI-2934: --- [~jgresock] It does seem related. Moreso to https://issues.apache.org/jira/browse/NIFI-2920 probably. Do you know if there was swapping involved and could you possible capture the lsof output related to the nifi process and share that or share as much details as you can. Every bit helps. > Archiver still not respecting > nifi.content.repository.archive.max.usage.percentage > -- > > Key: NIFI-2934 > URL: https://issues.apache.org/jira/browse/NIFI-2934 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 0.7.0, 0.7.1 >Reporter: Joseph Gresock > Attachments: Disk-Usage-Increasing.png, NiFi-80-percent-disk.png, > Queued.png, System-Diagnostics.png, content_repository usage.png > > > This seems related to NIFI-1726: we've noticed that the content repository > takes up increasingly more space over time, even beyond the configured max > usage percentage (see images). After restarting the NiFi cluster we get an > immediate drop in disk usage with lots of log statements indicating that > expired content is being removed. > Not sure if this is related, but we also often get "Too many open files" > during this expiration process after NiFi restart, despite lsof indicating a > count far lower than our configured nofile and fs-max. > In the environment indicated by the pictures, > nifi.content.repository.archive.max.usage.percentage = 50%. Note that the > flow itself only has ~240GB queued across the entire cluster, but each > content_repository directory has over 360GB on each worker. Also note the > disk usage graph increasing above 50% on each worker, until we finally > restart and then the usage drops below 50%. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (NIFI-2935) GetAzureEventHub freezes after certain period of reading data
Michiel Moonen created NIFI-2935: Summary: GetAzureEventHub freezes after certain period of reading data Key: NIFI-2935 URL: https://issues.apache.org/jira/browse/NIFI-2935 Project: Apache NiFi Issue Type: Bug Components: Core Framework Affects Versions: 0.7.0, 1.0.0 Reporter: Michiel Moonen We have a GetAzureEventHub processor running on a AWS instance to collect data from Azure. Runs quite smoothly, no heavy load (~140 kb / 30 seconds), but after 2 - 14 hours it just stops collecting data. GetAzureEventHub Processor block can be stopped in UI, but 'under the hood' actually it doesn't stop; processor block actually freezes / no response. Only option is to kill NiFi (which eventually terminates itself forcefully). Feels like some buffer has been flooded. I don't have logs atm, will add them soon. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2934) Archiver still not respecting nifi.content.repository.archive.max.usage.percentage
[ https://issues.apache.org/jira/browse/NIFI-2934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15601769#comment-15601769 ] Joseph Gresock commented on NIFI-2934: -- I wonder if this is related to NIFI-2925 > Archiver still not respecting > nifi.content.repository.archive.max.usage.percentage > -- > > Key: NIFI-2934 > URL: https://issues.apache.org/jira/browse/NIFI-2934 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 0.7.0, 0.7.1 >Reporter: Joseph Gresock > Attachments: Disk-Usage-Increasing.png, NiFi-80-percent-disk.png, > Queued.png, System-Diagnostics.png, content_repository usage.png > > > This seems related to NIFI-1726: we've noticed that the content repository > takes up increasingly more space over time, even beyond the configured max > usage percentage (see images). After restarting the NiFi cluster we get an > immediate drop in disk usage with lots of log statements indicating that > expired content is being removed. > Not sure if this is related, but we also often get "Too many open files" > during this expiration process after NiFi restart, despite lsof indicating a > count far lower than our configured nofile and fs-max. > In the environment indicated by the pictures, > nifi.content.repository.archive.max.usage.percentage = 50%. Note that the > flow itself only has ~240GB queued across the entire cluster, but each > content_repository directory has over 360GB on each worker. Also note the > disk usage graph increasing above 50% on each worker, until we finally > restart and then the usage drops below 50%. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-1022) Create GetTachyon and PutTachyon Processors
[ https://issues.apache.org/jira/browse/NIFI-1022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15601598#comment-15601598 ] ASF GitHub Bot commented on NIFI-1022: -- Github user pvillard31 commented on the issue: https://github.com/apache/nifi/pull/379 Hey guys, I've done some rework on this PR. After some discussions with Alluxio folks, it seems that there are some limitations at the moment (v1.3.0) and I've made some modifications to take into account those limitations. ### System properties At the moment, it seems it is not possible to initialize the Alluxio client inside NiFi without using system properties. And in any case, multi Alluxio clusters handling is not supported at the moment. ### Initialization Once the client is initialized, it cannot be unchanged unless NiFi is restarted. Even if provided IP/port are incorrect, the client initialization will not do any check. To avoid mistakes, I've added a simple check to ensure that something is listening at IP/port before initializing the client. *Improvement on Alluxio's side is tracked here: https://alluxio.atlassian.net/browse/ALLUXIO-2120* I've updated processors description to note it as **experimental** and let the users know what are the current limitations. Hopefully, this won't be a show stopper to get this first version into NiFi and get feedbacks from the community. > Create GetTachyon and PutTachyon Processors > --- > > Key: NIFI-1022 > URL: https://issues.apache.org/jira/browse/NIFI-1022 > Project: Apache NiFi > Issue Type: New Feature > Components: Extensions >Reporter: Jeremy Dyer >Assignee: Pierre Villard >Priority: Minor > Attachments: Alluxio.xml > > > Provide support for Apache Tachyon by implementing a GetTachyon and > PutTachyon processor. Having the ability to both read and write to Tachyon > would assist in sharing data with external applications such as Spark. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] nifi issue #379: NIFI-1022 Added Tachyon/Alluxio processors
Github user pvillard31 commented on the issue: https://github.com/apache/nifi/pull/379 Hey guys, I've done some rework on this PR. After some discussions with Alluxio folks, it seems that there are some limitations at the moment (v1.3.0) and I've made some modifications to take into account those limitations. ### System properties At the moment, it seems it is not possible to initialize the Alluxio client inside NiFi without using system properties. And in any case, multi Alluxio clusters handling is not supported at the moment. ### Initialization Once the client is initialized, it cannot be unchanged unless NiFi is restarted. Even if provided IP/port are incorrect, the client initialization will not do any check. To avoid mistakes, I've added a simple check to ensure that something is listening at IP/port before initializing the client. *Improvement on Alluxio's side is tracked here: https://alluxio.atlassian.net/browse/ALLUXIO-2120* I've updated processors description to note it as **experimental** and let the users know what are the current limitations. Hopefully, this won't be a show stopper to get this first version into NiFi and get feedbacks from the community. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Updated] (NIFI-2934) Archiver still not respecting nifi.content.repository.archive.max.usage.percentage
[ https://issues.apache.org/jira/browse/NIFI-2934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Gresock updated NIFI-2934: - Attachment: System-Diagnostics.png Queued.png NiFi-80-percent-disk.png Disk-Usage-Increasing.png > Archiver still not respecting > nifi.content.repository.archive.max.usage.percentage > -- > > Key: NIFI-2934 > URL: https://issues.apache.org/jira/browse/NIFI-2934 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 0.7.0, 0.7.1 >Reporter: Joseph Gresock > Attachments: Disk-Usage-Increasing.png, NiFi-80-percent-disk.png, > Queued.png, System-Diagnostics.png, content_repository usage.png > > > This seems related to NIFI-1726: we've noticed that the content repository > takes up increasingly more space over time, even beyond the configured max > usage percentage (see images). After restarting the NiFi cluster we get an > immediate drop in disk usage with lots of log statements indicating that > expired content is being removed. > Not sure if this is related, but we also often get "Too many open files" > during this expiration process after NiFi restart, despite lsof indicating a > count far lower than our configured nofile and fs-max. > In the environment indicated by the pictures, > nifi.content.repository.archive.max.usage.percentage = 50%. Note that the > flow itself only has ~240GB queued across the entire cluster, but each > content_repository directory has over 360GB on each worker. Also note the > disk usage graph increasing above 50% on each worker, until we finally > restart and then the usage drops below 50%. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (NIFI-2934) Archiver still not respecting nifi.content.repository.archive.max.usage.percentage
[ https://issues.apache.org/jira/browse/NIFI-2934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Gresock updated NIFI-2934: - Attachment: content_repository usage.png > Archiver still not respecting > nifi.content.repository.archive.max.usage.percentage > -- > > Key: NIFI-2934 > URL: https://issues.apache.org/jira/browse/NIFI-2934 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 0.7.0, 0.7.1 >Reporter: Joseph Gresock > Attachments: content_repository usage.png > > > This seems related to NIFI-1726: we've noticed that the content repository > takes up increasingly more space over time, even beyond the configured max > usage percentage (see images). After restarting the NiFi cluster we get an > immediate drop in disk usage with lots of log statements indicating that > expired content is being removed. > Not sure if this is related, but we also often get "Too many open files" > during this expiration process after NiFi restart, despite lsof indicating a > count far lower than our configured nofile and fs-max. > In the environment indicated by the pictures, > nifi.content.repository.archive.max.usage.percentage = 50%. Note that the > flow itself only has ~240GB queued across the entire cluster, but each > content_repository directory has over 360GB on each worker. Also note the > disk usage graph increasing above 50% on each worker, until we finally > restart and then the usage drops below 50%. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (NIFI-2934) Archiver still not respecting nifi.content.repository.archive.max.usage.percentage
Joseph Gresock created NIFI-2934: Summary: Archiver still not respecting nifi.content.repository.archive.max.usage.percentage Key: NIFI-2934 URL: https://issues.apache.org/jira/browse/NIFI-2934 Project: Apache NiFi Issue Type: Bug Affects Versions: 0.7.0, 0.7.1 Reporter: Joseph Gresock Attachments: content_repository usage.png This seems related to NIFI-1726: we've noticed that the content repository takes up increasingly more space over time, even beyond the configured max usage percentage (see images). After restarting the NiFi cluster we get an immediate drop in disk usage with lots of log statements indicating that expired content is being removed. Not sure if this is related, but we also often get "Too many open files" during this expiration process after NiFi restart, despite lsof indicating a count far lower than our configured nofile and fs-max. In the environment indicated by the pictures, nifi.content.repository.archive.max.usage.percentage = 50%. Note that the flow itself only has ~240GB queued across the entire cluster, but each content_repository directory has over 360GB on each worker. Also note the disk usage graph increasing above 50% on each worker, until we finally restart and then the usage drops below 50%. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-1151) Support large file transfer suspend/resume
[ https://issues.apache.org/jira/browse/NIFI-1151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15601144#comment-15601144 ] asanka sanjaya commented on NIFI-1151: -- Is there any update on this? > Support large file transfer suspend/resume > -- > > Key: NIFI-1151 > URL: https://issues.apache.org/jira/browse/NIFI-1151 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 0.3.0 >Reporter: Andrew Grande >Priority: Minor > > In a context of s2s protocol operations, we need to support resuming large > file transfers transparently instead of restarting on network failure. > Related to node affinity and chunking jiras. -- This message was sent by Atlassian JIRA (v6.3.4#6332)