[jira] [Commented] (NIFI-1856) ExecuteStreamCommand Needs to Consume Standard Error

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-1856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15871224#comment-15871224
 ] 

ASF GitHub Bot commented on NIFI-1856:
--

Github user rkarthik29 commented on a diff in the pull request:

https://github.com/apache/nifi/pull/1364#discussion_r101690678
  
--- Diff: 
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/ExecuteStreamCommand.java
 ---
@@ -287,6 +311,32 @@ protected PropertyDescriptor 
getSupportedDynamicPropertyDescriptor(final String
 .build();
 }
 
+@OnScheduled
+public void setupExecutor(final ProcessContext context) {
+executor = 
Executors.newFixedThreadPool(context.getMaxConcurrentTasks() * 2, new 
ThreadFactory() {
+private final ThreadFactory defaultFactory = 
Executors.defaultThreadFactory();
+
+@Override
+public Thread newThread(final Runnable r) {
+final Thread t = defaultFactory.newThread(r);
+t.setName("ExecuteStreamCommand " + getIdentifier() + " 
Task");
+return t;
+}
+});
+}
+
+@OnUnscheduled
--- End diff --

will do the change and submit.


> ExecuteStreamCommand Needs to Consume Standard Error
> 
>
> Key: NIFI-1856
> URL: https://issues.apache.org/jira/browse/NIFI-1856
> Project: Apache NiFi
>  Issue Type: Bug
>Reporter: Alan Jackoway
>Assignee: Karthik Narayanan
>
> I was using ExecuteStreamProcess to run certain hdfs commands that are tricky 
> to write in nifi but easy in bash (e.g. {{hadoop fs -rm -r 
> /data/*/2014/05/05}})
> However, my larger commands kept hanging even though when I run them from the 
> command line they finish quickly.
> Based on 
> http://www.javaworld.com/article/2071275/core-java/when-runtime-exec---won-t.html
>  I believe that ExecuteStreamCommand and possibly other processors need to 
> consume the standard error stream to prevent the processes from blocking when 
> standard error gets filled.
> To reproduce. Create this as ~/write.py
> {code:python}
> import sys
> count = int(sys.argv[1])
> for x in range(count):
> sys.stderr.write("ERROR %d\n" % x)
> sys.stdout.write("OUTPUT %d\n" % x)
> {code}
> Create a flow that goes 
> # GenerateFlowFile - 5 minutes schedule 0 bytes size 
> # ExecuteStreamCommand - Command arguments /Users/alanj/write.py;100 Command 
> Path python
> # PutFile - /tmp/write/
> routing output stream of ExecuteStreamCommand to PutFile
> When you turn everything on, you get 100 lines (not 200) of just the standard 
> output in /tmp/write.
> Next, change the command arguments to /Users/alanj/write.py;10 and turn 
> everything on again. The command will hang.
> I believe that whenever you execute a process the way ExecuteStreamCommand is 
> doing, you need to consume the standard error stream to keep it from 
> blocking. This may also affect things like ExecuteProcess and ExecuteScript 
> as well.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] nifi pull request #1364: NIFI-1856 ExecuteStreamCommand Needs to Consume Sta...

[rkarthik29]

Github user rkarthik29 commented on a diff in the pull request:

https://github.com/apache/nifi/pull/1364#discussion_r101690678
  
--- Diff: 
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/ExecuteStreamCommand.java
 ---
@@ -287,6 +311,32 @@ protected PropertyDescriptor 
getSupportedDynamicPropertyDescriptor(final String
 .build();
 }
 
+@OnScheduled
+public void setupExecutor(final ProcessContext context) {
+executor = 
Executors.newFixedThreadPool(context.getMaxConcurrentTasks() * 2, new 
ThreadFactory() {
+private final ThreadFactory defaultFactory = 
Executors.defaultThreadFactory();
+
+@Override
+public Thread newThread(final Runnable r) {
+final Thread t = defaultFactory.newThread(r);
+t.setName("ExecuteStreamCommand " + getIdentifier() + " 
Task");
+return t;
+}
+});
+}
+
+@OnUnscheduled
--- End diff --

will do the change and submit.


---
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-3382) Regenerate Test Certificates for NiFi-Web-Api in 0.x

[Andy LoPresto (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-3382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy LoPresto updated NIFI-3382:

Affects Version/s: (was: 0.8.0)
   0.7.1

> Regenerate Test Certificates for NiFi-Web-Api in 0.x
> 
>
> Key: NIFI-3382
> URL: https://issues.apache.org/jira/browse/NIFI-3382
> Project: Apache NiFi
>  Issue Type: Task
>  Components: Core Framework
>Affects Versions: 0.7.1
>Reporter: James Wing
>Assignee: James Wing
>Priority: Critical
> Fix For: 0.8.0, 0.7.2
>
>
> The certificates used by unit tests in nifi-web-api expired January 5, 2017.  
> The 0.x build has been failing since then reporting errors about the failed 
> certificates:
> {quote}
> java.lang.Exception: Unable to populate initial flow: Client certificate for 
> (CN=localhost, OU=Apache NiFi, O=Apache, L=Santa Monica, ST=CA, C=US) is 
> expired.
> {quote}
> The certificate expiration issue for the master branch is being pursued in 
> NIFI-3251.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (NIFI-3382) Regenerate Test Certificates for NiFi-Web-Api in 0.x

[Andy LoPresto (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-3382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy LoPresto updated NIFI-3382:

Fix Version/s: 0.7.2

> Regenerate Test Certificates for NiFi-Web-Api in 0.x
> 
>
> Key: NIFI-3382
> URL: https://issues.apache.org/jira/browse/NIFI-3382
> Project: Apache NiFi
>  Issue Type: Task
>  Components: Core Framework
>Affects Versions: 0.7.1
>Reporter: James Wing
>Assignee: James Wing
>Priority: Critical
> Fix For: 0.8.0, 0.7.2
>
>
> The certificates used by unit tests in nifi-web-api expired January 5, 2017.  
> The 0.x build has been failing since then reporting errors about the failed 
> certificates:
> {quote}
> java.lang.Exception: Unable to populate initial flow: Client certificate for 
> (CN=localhost, OU=Apache NiFi, O=Apache, L=Santa Monica, ST=CA, C=US) is 
> expired.
> {quote}
> The certificate expiration issue for the master branch is being pursued in 
> NIFI-3251.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (NIFI-3489) Release Apache NiFi 0.7.2

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15871142#comment-15871142
 ] 

ASF subversion and git services commented on NIFI-3489:
---

Commit dd15d5f3301d4b74f9da0dbebedb84d1e48b30f9 in nifi's branch 
refs/heads/NIFI-3489-RC1 from [~alopresto]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=dd15d5f ]

NIFI-3489-RC1 prepare for next development iteration


> Release Apache NiFi 0.7.2
> -
>
> Key: NIFI-3489
> URL: https://issues.apache.org/jira/browse/NIFI-3489
> Project: Apache NiFi
>  Issue Type: Task
>  Components: Tools and Build
>Affects Versions: 0.7.2
>Reporter: Andy LoPresto
>Assignee: Andy LoPresto
>  Labels: release
> Fix For: 0.7.2
>
>
> Perform release management tasks. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (NIFI-3489) Release Apache NiFi 0.7.2

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15871141#comment-15871141
 ] 

ASF subversion and git services commented on NIFI-3489:
---

Commit 831ac6939df7d418cadb336eedb4e09fb97541a1 in nifi's branch 
refs/heads/NIFI-3489-RC1 from [~alopresto]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=831ac69 ]

NIFI-3489-RC1 prepare release nifi-0.7.2-RC1


> Release Apache NiFi 0.7.2
> -
>
> Key: NIFI-3489
> URL: https://issues.apache.org/jira/browse/NIFI-3489
> Project: Apache NiFi
>  Issue Type: Task
>  Components: Tools and Build
>Affects Versions: 0.7.2
>Reporter: Andy LoPresto
>Assignee: Andy LoPresto
>  Labels: release
> Fix For: 0.7.2
>
>
> Perform release management tasks. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (NIFI-3354) Create CSV To Avro transformer

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15871137#comment-15871137
 ] 

ASF GitHub Bot commented on NIFI-3354:
--

Github user joewitt commented on the issue:

https://github.com/apache/nifi/pull/1436
  
I've attached a template used to validate the behavior.  once 
licensing/notice is updated I think this is good to go.  In testing this it 
exposed the issue described and addressed here: 
https://issues.apache.org/jira/browse/NIFI-3495


> Create CSV To Avro transformer
> --
>
> Key: NIFI-3354
> URL: https://issues.apache.org/jira/browse/NIFI-3354
> Project: Apache NiFi
>  Issue Type: Sub-task
>Reporter: Oleg Zhurakousky
>Assignee: Oleg Zhurakousky
> Fix For: 1.2.0
>
> Attachments: csv_content.txt, NIFI-3354.xml, 
> Test_Transform_CSV_to_JSON_to_CSV.xml
>
>
> While we currently have CSV to AVRO transformer it required HDFS/Kite 
> dependencies which could be easily eliminated.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] nifi issue #1436: NIFI-3354 Added support for simple AVRO/CSV/JSON transform...

[joewitt]

Github user joewitt commented on the issue:

https://github.com/apache/nifi/pull/1436
  
I've attached a template used to validate the behavior.  once 
licensing/notice is updated I think this is good to go.  In testing this it 
exposed the issue described and addressed here: 
https://issues.apache.org/jira/browse/NIFI-3495


---
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-3495) TextLineDemarcator sets the wrong index when read ahead is performed in isEol operation

[Joseph Witt (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15871136#comment-15871136
 ] 

Joseph Witt commented on NIFI-3495:
---

i have verified that this corrects the issue observed.  Before this patch data 
from this site when split would split very incorrectly.  After this patch it 
appears to split the results perfectly.

http://standards.ieee.org/develop/regauth/oui/oui.csv

It still needs a code review

> TextLineDemarcator sets the wrong index when read ahead is performed in isEol 
> operation
> ---
>
> Key: NIFI-3495
> URL: https://issues.apache.org/jira/browse/NIFI-3495
> Project: Apache NiFi
>  Issue Type: Bug
>Reporter: Oleg Zhurakousky
>Assignee: Oleg Zhurakousky
>Priority: Critical
> Fix For: 1.2.0
>
>
> This condition is very rare. It only occurs when read ahead (call to 
> _fill()_)  is made inside of the _isEol_ operation which essentially sets the 
> new index which then is reset inside of the main _nextOffsetInfo_ operation. 
> So the fix is to basically monitor if _isEol_ had to perform read ahead and 
> if it did do not reset the index.
> More details.
> While this component is modeled after standard Java BufferedReader which 
> simply reads and returns lines (delimited by CR or LF or both), this reader 
> also holds the information about how each line terminated (i.e., EOF, or CR 
> or LF or CR and LF) returning it to the caller as OffsetInfo. 
> So for example if you have a record "foo\r\nbar" and you read it with 
> BuffereReader you will get 'foo' and 'bar'. However you will not know that 
> between the two tokens there was CR and LF and therefore will not be able to 
> restore (if need to) the record to its original state. The TextLineDemarcator 
> will return OffsetInfo which holds the delimiter and other information.
> So, to accomplish the above every time we see CR (13) we need to peek at the 
> next byte and see if its LF(10). When at the end of the buffer such peek 
> becomes complicated since we need to read more data and so we did, but didn't 
> handle index properly essentially setting it back to the old value when the 
> new one was set inside of the fill().



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (NIFI-3354) Create CSV To Avro transformer

[Joseph Witt (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-3354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joseph Witt updated NIFI-3354:
--
Attachment: Test_Transform_CSV_to_JSON_to_CSV.xml

> Create CSV To Avro transformer
> --
>
> Key: NIFI-3354
> URL: https://issues.apache.org/jira/browse/NIFI-3354
> Project: Apache NiFi
>  Issue Type: Sub-task
>Reporter: Oleg Zhurakousky
>Assignee: Oleg Zhurakousky
> Fix For: 1.2.0
>
> Attachments: csv_content.txt, NIFI-3354.xml, 
> Test_Transform_CSV_to_JSON_to_CSV.xml
>
>
> While we currently have CSV to AVRO transformer it required HDFS/Kite 
> dependencies which could be easily eliminated.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (NIFI-3496) Create guide on how to diagnose/troubleshoot instance problems

[Aldrin Piri (JIRA)]

Aldrin Piri created NIFI-3496:
-

 Summary: Create guide on how to diagnose/troubleshoot instance 
problems
 Key: NIFI-3496
 URL: https://issues.apache.org/jira/browse/NIFI-3496
 Project: Apache NiFi
  Issue Type: Improvement
  Components: Documentation & Website
Reporter: Aldrin Piri


Getting into the internals of the system when problems arise surfaces on the 
mailing list with some regularity.  Until we have better tooling built into 
NiFi, it would be helpful to have a basic checklist/workflow of items to check 
and provide to folks on the mailing list such that we can get a list of best 
practices and techniques to help us be more effective in providing guidance.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (NIFI-3362) Update FlowConfiguration.xsd TimePeriod to match FormatUtils

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15871069#comment-15871069
 ] 

ASF GitHub Bot commented on NIFI-3362:
--

Github user apiri commented on the issue:

https://github.com/apache/nifi/pull/1509
  
@mosermw I guess since this isn't going into master, the magical "closes" 
statement won't register.  Could you please close this when you have the 
opportunity?  Thanks!


> Update FlowConfiguration.xsd TimePeriod to match FormatUtils
> 
>
> Key: NIFI-3362
> URL: https://issues.apache.org/jira/browse/NIFI-3362
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 0.7.1, 1.1.1
>Reporter: Michael Moser
>Assignee: Michael Moser
>Priority: Minor
> Fix For: 1.2.0
>
>
> The framework FormatUtils time duration parser has been updated to support 
> new terms such as "weeks".  But when using those new terms, we get ERROR 
> messages in the nifi-bootstrap.log.
> cvc-pattern-valid: Value '4 weeks' is not facet-valid with respect to pattern 
> '\d+\s*(ns|nano|nanos|nanoseconds|ms|milli|millis|milliseconds|s|sec|secs|seconds|m|min|mins|minutes|h|hr|hrs|hours|d|day|days)'
>  for type 'TimePeriod'.
> cvc-type.3.1.3: The value '4 weeks' of element 'flowFileExpiration' is not 
> valid.
> FlowConfiguration.xsd TimePeriod pattern should be updated to match 
> FormatUtils.
> Add to FlowConguration.xsd:
> nanosecond
> millisecond
> second
> minute
> hour
> w
> wk
> wks
> week
> weeks
> Add to FormatUtils.java
> nanosecond
> millisecond



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] nifi issue #1509: NIFI-3362 update FlowConfiguration.xsd to allow all curren...

[apiri]

Github user apiri commented on the issue:

https://github.com/apache/nifi/pull/1509
  
@mosermw I guess since this isn't going into master, the magical "closes" 
statement won't register.  Could you please close this when you have the 
opportunity?  Thanks!


---
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-3362) Update FlowConfiguration.xsd TimePeriod to match FormatUtils

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15871066#comment-15871066
 ] 

ASF GitHub Bot commented on NIFI-3362:
--

Github user apiri commented on the issue:

https://github.com/apache/nifi/pull/1509
  
@mosermw No problem and seems okay.  Was able to verify anticipated 
behavior for this and will get merged.


> Update FlowConfiguration.xsd TimePeriod to match FormatUtils
> 
>
> Key: NIFI-3362
> URL: https://issues.apache.org/jira/browse/NIFI-3362
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 0.7.1, 1.1.1
>Reporter: Michael Moser
>Assignee: Michael Moser
>Priority: Minor
> Fix For: 1.2.0
>
>
> The framework FormatUtils time duration parser has been updated to support 
> new terms such as "weeks".  But when using those new terms, we get ERROR 
> messages in the nifi-bootstrap.log.
> cvc-pattern-valid: Value '4 weeks' is not facet-valid with respect to pattern 
> '\d+\s*(ns|nano|nanos|nanoseconds|ms|milli|millis|milliseconds|s|sec|secs|seconds|m|min|mins|minutes|h|hr|hrs|hours|d|day|days)'
>  for type 'TimePeriod'.
> cvc-type.3.1.3: The value '4 weeks' of element 'flowFileExpiration' is not 
> valid.
> FlowConfiguration.xsd TimePeriod pattern should be updated to match 
> FormatUtils.
> Add to FlowConguration.xsd:
> nanosecond
> millisecond
> second
> minute
> hour
> w
> wk
> wks
> week
> weeks
> Add to FormatUtils.java
> nanosecond
> millisecond



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] nifi issue #1509: NIFI-3362 update FlowConfiguration.xsd to allow all curren...

[apiri]

Github user apiri commented on the issue:

https://github.com/apache/nifi/pull/1509
  
@mosermw No problem and seems okay.  Was able to verify anticipated 
behavior for this and will get merged.


---
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-3495) TextLineDemarcator sets the wrong index when read ahead is performed in isEol operation

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15871056#comment-15871056
 ] 

ASF GitHub Bot commented on NIFI-3495:
--

GitHub user olegz opened a pull request:

https://github.com/apache/nifi/pull/1518

NIFI-3495 fixed the index issue with TextLineDemarcator

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:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced 
 in the commit message?

- [ ] Does your PR title start with NIFI- where  is the JIRA number 
you are trying to resolve? Pay particular attention to the hyphen "-" character.

- [ ] Has your PR been rebased against the latest commit within the target 
branch (typically master)?

- [ ] Is your initial contribution a single, squashed commit?

### For code changes:
- [ ] Have you ensured that the full suite of tests is executed via mvn 
-Pcontrib-check clean install at the root nifi 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 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.


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/olegz/nifi NIFI-3495

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/nifi/pull/1518.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 #1518


commit d65ceef58adc448cfa321411d5f4651459063e1c
Author: Oleg Zhurakousky 
Date:   2017-02-17T02:05:59Z

NIFI-3495 fixed the index issue with TextLineDemarcator




> TextLineDemarcator sets the wrong index when read ahead is performed in isEol 
> operation
> ---
>
> Key: NIFI-3495
> URL: https://issues.apache.org/jira/browse/NIFI-3495
> Project: Apache NiFi
>  Issue Type: Bug
>Reporter: Oleg Zhurakousky
>Assignee: Oleg Zhurakousky
>Priority: Critical
> Fix For: 1.2.0
>
>
> This condition is very rare. It only occurs when read ahead (call to 
> _fill()_)  is made inside of the _isEol_ operation which essentially sets the 
> new index which then is reset inside of the main _nextOffsetInfo_ operation. 
> So the fix is to basically monitor if _isEol_ had to perform read ahead and 
> if it did do not reset the index.
> More details.
> While this component is modeled after standard Java BufferedReader which 
> simply reads and returns lines (delimited by CR or LF or both), this reader 
> also holds the information about how each line terminated (i.e., EOF, or CR 
> or LF or CR and LF) returning it to the caller as OffsetInfo. 
> So for example if you have a record "foo\r\nbar" and you read it with 
> BuffereReader you will get 'foo' and 'bar'. However you will not know that 
> between the two tokens there was CR and LF and therefore will not be able to 
> restore (if need to) the record to its original state. The TextLineDemarcator 
> will return OffsetInfo which holds the delimiter and other information.
> So, to accomplish the above every time we see CR (13) we need to peek at the 
> next byte and see if its LF(10). When at the end of the buffer such peek 
> becomes complicated since we need to read more data and so we did, but didn't 
> handle index properly essentially setting it back to the old value when the 
> new one was set inside of the fill().



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] nifi pull request #1518: NIFI-3495 fixed the index issue with TextLineDemarc...

[olegz]

GitHub user olegz opened a pull request:

https://github.com/apache/nifi/pull/1518

NIFI-3495 fixed the index issue with TextLineDemarcator

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:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced 
 in the commit message?

- [ ] Does your PR title start with NIFI- where  is the JIRA number 
you are trying to resolve? Pay particular attention to the hyphen "-" character.

- [ ] Has your PR been rebased against the latest commit within the target 
branch (typically master)?

- [ ] Is your initial contribution a single, squashed commit?

### For code changes:
- [ ] Have you ensured that the full suite of tests is executed via mvn 
-Pcontrib-check clean install at the root nifi 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 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.


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/olegz/nifi NIFI-3495

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/nifi/pull/1518.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 #1518


commit d65ceef58adc448cfa321411d5f4651459063e1c
Author: Oleg Zhurakousky 
Date:   2017-02-17T02:05:59Z

NIFI-3495 fixed the index issue with TextLineDemarcator




---
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-3486) Release Apache NiFi 1.1.2

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15871055#comment-15871055
 ] 

ASF subversion and git services commented on NIFI-3486:
---

Commit 51fad01f5daf33716b8b5379c32ee932d91c8c63 in nifi's branch 
refs/heads/NIFI-3486-RC1 from [~alopresto]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=51fad01 ]

NIFI-3486-RC1 prepare for next development iteration


> Release Apache NiFi 1.1.2
> -
>
> Key: NIFI-3486
> URL: https://issues.apache.org/jira/browse/NIFI-3486
> Project: Apache NiFi
>  Issue Type: Task
>  Components: Tools and Build
>Affects Versions: 1.1.2
>Reporter: Andy LoPresto
>Assignee: Andy LoPresto
>  Labels: release
> Fix For: 1.1.2
>
>
> Perform RM tasks for the release. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (NIFI-3213) ListFile always skips files with the latest timestamp in an iteration even if the files have existed a while ago

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15871053#comment-15871053
 ] 

ASF GitHub Bot commented on NIFI-3213:
--

Github user ijokarumawak commented on the issue:

https://github.com/apache/nifi/pull/1335
  
@trixpan Since the failing test has more Thread.sleep calls than before, 
the meaning of variables such as `age1` or `age2` became fragile at the later 
part of the test. I added another commit to fix the test case. Also, rebased it 
with the latest master just in case.

Thanks again for caching this test issue. Please review the test again, and 
let me know if you want me to squash commits.


> ListFile always skips files with the latest timestamp in an iteration even if 
> the files have existed a while ago
> 
>
> Key: NIFI-3213
> URL: https://issues.apache.org/jira/browse/NIFI-3213
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: 1.0.0, 0.5.0, 0.6.0, 0.5.1, 0.7.0, 0.6.1, 1.1.0, 0.7.1
>Reporter: Koji Kawamura
>Assignee: Koji Kawamura
>
> NIFI-1484 add few lines of code to avoid files to be emitted if those have 
> the latest timestamp within an iteration of listing, because it may still be 
> written at the same time.
> While it doesn't affect much if ListFiles processor is scheduled with a short 
> period of time, such as few ms, but it does affect negatively if an user 
> scheduled it with longer run schedule such as "1 day" or with cron scheduler. 
> For example, user would expect to process list of files per daily basis. Even 
> if a file is saved few hours ago, the processor will skip this, because the 
> file has the latest timestamp within the iteration.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] nifi issue #1335: NIFI-3213: ListFile - Do not skip obviously old files.

[ijokarumawak]

Github user ijokarumawak commented on the issue:

https://github.com/apache/nifi/pull/1335
  
@trixpan Since the failing test has more Thread.sleep calls than before, 
the meaning of variables such as `age1` or `age2` became fragile at the later 
part of the test. I added another commit to fix the test case. Also, rebased it 
with the latest master just in case.

Thanks again for caching this test issue. Please review the test again, and 
let me know if you want me to squash commits.


---
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-3495) TextLineDemarcator sets the wrong index when read ahead is performed in isEol operation

[Oleg Zhurakousky (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-3495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Zhurakousky updated NIFI-3495:
---
Description: 
This condition is very rare. It only occurs when read ahead (call to _fill()_)  
is made inside of the _isEol_ operation which essentially sets the new index 
which then is reset inside of the main _nextOffsetInfo_ operation. 
So the fix is to basically monitor if _isEol_ had to perform read ahead and if 
it did do not reset the index.

More details.
While this component is modeled after standard Java BufferedReader which simply 
reads and returns lines (delimited by CR or LF or both), this reader also holds 
the information about how each line terminated (i.e., EOF, or CR or LF or CR 
and LF) returning it to the caller as OffsetInfo. 
So for example if you have a record "foo\r\nbar" and you read it with 
BuffereReader you will get 'foo' and 'bar'. However you will not know that 
between the two tokens there was CR and LF and therefore will not be able to 
restore (if need to) the record to its original state. The TextLineDemarcator 
will return OffsetInfo which holds the delimiter and other information.

So, to accomplish the above every time we see CR (13) we need to peek at the 
next byte and see if its LF(10). When at the end of the buffer such peek 
becomes complicated since we need to read more data and so we did, but didn't 
handle index properly essentially setting it back to the old value when the new 
one was set inside of the fill().

  was:
This condition is very rare. It only occurs when read ahead (call to _fill()_)  
is made inside of the _isEol_ operation which essentially sets the new index 
which then is reset inside of the main _nextOffsetInfo_ operation. 
So the fix is to basically monitor if _isEol_ had to perform read ahead and if 
it did do not reset the index.


> TextLineDemarcator sets the wrong index when read ahead is performed in isEol 
> operation
> ---
>
> Key: NIFI-3495
> URL: https://issues.apache.org/jira/browse/NIFI-3495
> Project: Apache NiFi
>  Issue Type: Bug
>Reporter: Oleg Zhurakousky
>Assignee: Oleg Zhurakousky
>Priority: Critical
> Fix For: 1.2.0
>
>
> This condition is very rare. It only occurs when read ahead (call to 
> _fill()_)  is made inside of the _isEol_ operation which essentially sets the 
> new index which then is reset inside of the main _nextOffsetInfo_ operation. 
> So the fix is to basically monitor if _isEol_ had to perform read ahead and 
> if it did do not reset the index.
> More details.
> While this component is modeled after standard Java BufferedReader which 
> simply reads and returns lines (delimited by CR or LF or both), this reader 
> also holds the information about how each line terminated (i.e., EOF, or CR 
> or LF or CR and LF) returning it to the caller as OffsetInfo. 
> So for example if you have a record "foo\r\nbar" and you read it with 
> BuffereReader you will get 'foo' and 'bar'. However you will not know that 
> between the two tokens there was CR and LF and therefore will not be able to 
> restore (if need to) the record to its original state. The TextLineDemarcator 
> will return OffsetInfo which holds the delimiter and other information.
> So, to accomplish the above every time we see CR (13) we need to peek at the 
> next byte and see if its LF(10). When at the end of the buffer such peek 
> becomes complicated since we need to read more data and so we did, but didn't 
> handle index properly essentially setting it back to the old value when the 
> new one was set inside of the fill().



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (NIFI-3495) TextLineDemarcator sets the wrong index when read ahead is performed in isEol operation

[Oleg Zhurakousky (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-3495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Zhurakousky updated NIFI-3495:
---
Description: 
This condition is very rare. It only occurs when read ahead (call to _fill()_)  
is made inside of the _isEol_ operation which essentially sets the new index 
which then is reset inside of the main _nextOffsetInfo_ operation. 
So the fix is to basically monitor if _isEol_ had to perform read ahead and if 
it did do not reset the index.

  was:
This condition is very rare. It only occurs when read ahead (call to _fill()_)  
is made inside of the _isEol_ operation which essentially sets the new index 
which then is reset inside of the main _nextOffsetInfo_ operation. 
So the fox is to basically monitor if _isEol_ had tio perform read ahead and if 
it did do not reset the index.


> TextLineDemarcator sets the wrong index when read ahead is performed in isEol 
> operation
> ---
>
> Key: NIFI-3495
> URL: https://issues.apache.org/jira/browse/NIFI-3495
> Project: Apache NiFi
>  Issue Type: Bug
>Reporter: Oleg Zhurakousky
>Assignee: Oleg Zhurakousky
>Priority: Critical
> Fix For: 1.2.0
>
>
> This condition is very rare. It only occurs when read ahead (call to 
> _fill()_)  is made inside of the _isEol_ operation which essentially sets the 
> new index which then is reset inside of the main _nextOffsetInfo_ operation. 
> So the fix is to basically monitor if _isEol_ had to perform read ahead and 
> if it did do not reset the index.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (NIFI-3495) TextLineDemarcator sets the wrong index when read ahead is performed in isEol operation

[Oleg Zhurakousky (JIRA)]

Oleg Zhurakousky created NIFI-3495:
--

 Summary: TextLineDemarcator sets the wrong index when read ahead 
is performed in isEol operation
 Key: NIFI-3495
 URL: https://issues.apache.org/jira/browse/NIFI-3495
 Project: Apache NiFi
  Issue Type: Bug
Reporter: Oleg Zhurakousky
Assignee: Oleg Zhurakousky
Priority: Critical
 Fix For: 1.2.0


This condition is very rare. It only occurs when read ahead (call to _fill()_)  
is made inside of the _isEol_ operation which essentially sets the new index 
which then is reset inside of the main _nextOffsetInfo_ operation. 
So the fox is to basically monitor if _isEol_ had tio perform read ahead and if 
it did do not reset the index.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (NIFI-3142) ExtractHL7Attributes processor does not route to REL_FAILURE for an exception other than an HL7Exception

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15870960#comment-15870960
 ] 

ASF GitHub Bot commented on NIFI-3142:
--

Github user trixpan commented on the issue:

https://github.com/apache/nifi/pull/1290
  
@klinvill 

Is this PR still needed or was it identified as a data quality issue?


> ExtractHL7Attributes processor does not route to REL_FAILURE for an exception 
> other than an HL7Exception
> 
>
> Key: NIFI-3142
> URL: https://issues.apache.org/jira/browse/NIFI-3142
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: 1.0.0
>Reporter: Kirby Linvill
>Priority: Minor
>  Labels: easyfix
>
> The ExtractHL7Attribute processor will not route a flowfile to REL_FAILURE if 
> processing the flow file throws an exception that is not an HL7Exception. 
> This bug is a result of the try catch block in the onTrigger method. It is 
> easily fixed by changing the catch block to catch a throwable object. Change
> {noformat} 
> try {
> ...
> } catch (final HL7Exception e) {
> getLogger().error("Failed to extract attributes from {} due to {}", new 
> Object[]{flowFile, e}, e);
> session.transfer(flowFile, REL_FAILURE);
> return;
> }
> {noformat} 
> to 
> {noformat} 
> try {
> ...
> } catch (final Throwable t) {
> getLogger().error("Failed to extract attributes from {} due to {}", new 
> Object[]{flowFile, t}, t);
> session.transfer(flowFile, REL_FAILURE);
> return;
> }
> {noformat} 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] nifi issue #1290: Fix NIFI-3142: ExtractHL7Attribute processor: Route a flow...

[trixpan]

Github user trixpan commented on the issue:

https://github.com/apache/nifi/pull/1290
  
@klinvill 

Is this PR still needed or was it identified as a data quality issue?


---
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-2724) JMX Processor

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15870815#comment-15870815
 ] 

ASF GitHub Bot commented on NIFI-2724:
--

Github user trixpan commented on the issue:

https://github.com/apache/nifi/pull/1016
  
@brianburnett 

I suspect the reason for that is because you are trying to cherry-pick from 
the branch you already have a commit.

Note how I suggested you to circle around...

First step is to create a new branch from master. If you master already has 
the commit then you can use the upstream/master as a base (assuming you gave 
the github.com/apache/nifi remote the name of upstream)

`git checkout origin master -b nifi-2724v2`

If you do `git log` you should see the last commit as being whatever has 
been just published to the NiFi master git and also be told by `git status` 
that you are using nifi-2724v2`

Now you perform a cherry pick that will copy your changes from the old 
nifi-2742 branch into to the branch (i.e. nifi-2724v2) you just created.


> JMX Processor
> -
>
> Key: NIFI-2724
> URL: https://issues.apache.org/jira/browse/NIFI-2724
> Project: Apache NiFi
>  Issue Type: New Feature
>  Components: Extensions
>Affects Versions: 1.0.0
> Environment: All platforms with Java RMI support for JMX
>Reporter: Brian Burnett
>Assignee: Andre
>Priority: Minor
>  Labels: processor
> Attachments: 0001-NIFI-2724-New-JMX-Processor.patch
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> The JMX Processor feature addition includes only GetJMX without 
> SecurityManager capabilities at this time.  The processor in its current 
> state is capable of pulling MBean Property and Attribute values from a remote 
> RMI Server.  Each set of Mbean data is wrapped in a JSON formatted FlowFile 
> for downstream processing.  It has the ability to control content with 
> whitelist and blacklist properties.
> Possible use for this processor and the reason it was created is to help make 
> sense of Kafka server metrics.
> Will followup with a SecurityManager Context Service and PutJMX Processor.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] nifi issue #1016: NIFI-2724 New JMX Processor

[trixpan]

Github user trixpan commented on the issue:

https://github.com/apache/nifi/pull/1016
  
@brianburnett 

I suspect the reason for that is because you are trying to cherry-pick from 
the branch you already have a commit.

Note how I suggested you to circle around...

First step is to create a new branch from master. If you master already has 
the commit then you can use the upstream/master as a base (assuming you gave 
the github.com/apache/nifi remote the name of upstream)

`git checkout origin master -b nifi-2724v2`

If you do `git log` you should see the last commit as being whatever has 
been just published to the NiFi master git and also be told by `git status` 
that you are using nifi-2724v2`

Now you perform a cherry pick that will copy your changes from the old 
nifi-2742 branch into to the branch (i.e. nifi-2724v2) you just created.


---
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-3488) Add LocalMapCacheService

[Peter Wicks (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-3488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Peter Wicks reassigned NIFI-3488:
-

Assignee: Peter Wicks

> Add LocalMapCacheService
> 
>
> Key: NIFI-3488
> URL: https://issues.apache.org/jira/browse/NIFI-3488
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Koji Kawamura
>Assignee: Peter Wicks
>
> Currently we have DistributedMapCacheClientService to share values among 
> different processors across NiFi nodes. However it can be an extravagance if 
> users would like to use the cache only for sharing values locally within a 
> node instead of cluster wide.
> LocalMapCacheService can be useful in that cases, provides benefits such as, 
> being able to use existing Processors those use DistributedMapCacheClient, no 
> need to transfer data over network, don't have to worry about cache key 
> collision ... etc.
> The implementation can be as simple as having a Map on heap. Optionally 
> persist MapEntries to local filesystem.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] nifi issue #1405: NIFI-3294 Adjusting nifi.sh to invoke nifi-env.sh

[apiri]

Github user apiri commented on the issue:

https://github.com/apache/nifi/pull/1405
  
@ijokarumawak Believe I have corrected the issue.  Created a similar flow 
of GenerateFlowFile -> UpdateAttribute -> LogAttribute and verified successful 
passing of environment variables into NiFi.  The updated commit additionally 
merged in the changes to resolve the previous conflict.


---
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-3294) NiFi will ignore nifi-env properties when running as another user

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15870795#comment-15870795
 ] 

ASF GitHub Bot commented on NIFI-3294:
--

Github user apiri commented on the issue:

https://github.com/apache/nifi/pull/1405
  
@ijokarumawak Believe I have corrected the issue.  Created a similar flow 
of GenerateFlowFile -> UpdateAttribute -> LogAttribute and verified successful 
passing of environment variables into NiFi.  The updated commit additionally 
merged in the changes to resolve the previous conflict.


> NiFi will ignore nifi-env properties when running as another user
> -
>
> Key: NIFI-3294
> URL: https://issues.apache.org/jira/browse/NIFI-3294
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Configuration
>Affects Versions: 1.0.0, 0.7.0, 0.7.1, 1.1.1, 1.0.1
> Environment: All non-Windows, non-Cygwin OSes
>Reporter: Aldrin Piri
>Assignee: Aldrin Piri
> Fix For: 0.8.0, 1.2.0
>
>
> nifi-env is a script that allows setting of certain properties external to 
> the core run scripts.  However, when sudo is used, the resulting 
> subshell/child process is a separate environment that does not have the 
> needed information that was established in nifi-env.  This needs to be 
> incorporated into the run command such that those properties are preserved.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (NIFI-2724) JMX Processor

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15870785#comment-15870785
 ] 

ASF GitHub Bot commented on NIFI-2724:
--

Github user brianburnett commented on the issue:

https://github.com/apache/nifi/pull/1016
  
$git log
commit df73bdc7f0f13d4f21b23a8a0a41f78fa0386aa2
Author: brianburnett 
Date:   Thu Feb 16 11:55:55 2017 -0500

NIFI-2724 JMX Processor 1.2.0 rev

$git cherry-pick df73bdc7f0f13d4f21b23a8a0a41f78fa0386aa2
On branch nifi-2724v2
You are currently cherry-picking commit df73bdc.

nothing to commit, working tree clean
The previous cherry-pick is now empty, possibly due to conflict resolution.
If you wish to commit it anyway, use:

git commit --allow-empty

Otherwise, please use 'git reset'


Shall I do the git commit --allow-empty?


> JMX Processor
> -
>
> Key: NIFI-2724
> URL: https://issues.apache.org/jira/browse/NIFI-2724
> Project: Apache NiFi
>  Issue Type: New Feature
>  Components: Extensions
>Affects Versions: 1.0.0
> Environment: All platforms with Java RMI support for JMX
>Reporter: Brian Burnett
>Assignee: Andre
>Priority: Minor
>  Labels: processor
> Attachments: 0001-NIFI-2724-New-JMX-Processor.patch
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> The JMX Processor feature addition includes only GetJMX without 
> SecurityManager capabilities at this time.  The processor in its current 
> state is capable of pulling MBean Property and Attribute values from a remote 
> RMI Server.  Each set of Mbean data is wrapped in a JSON formatted FlowFile 
> for downstream processing.  It has the ability to control content with 
> whitelist and blacklist properties.
> Possible use for this processor and the reason it was created is to help make 
> sense of Kafka server metrics.
> Will followup with a SecurityManager Context Service and PutJMX Processor.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] nifi issue #1016: NIFI-2724 New JMX Processor

[brianburnett]

Github user brianburnett commented on the issue:

https://github.com/apache/nifi/pull/1016
  
$git log
commit df73bdc7f0f13d4f21b23a8a0a41f78fa0386aa2
Author: brianburnett 
Date:   Thu Feb 16 11:55:55 2017 -0500

NIFI-2724 JMX Processor 1.2.0 rev

$git cherry-pick df73bdc7f0f13d4f21b23a8a0a41f78fa0386aa2
On branch nifi-2724v2
You are currently cherry-picking commit df73bdc.

nothing to commit, working tree clean
The previous cherry-pick is now empty, possibly due to conflict resolution.
If you wish to commit it anyway, use:

git commit --allow-empty

Otherwise, please use 'git reset'


Shall I do the git commit --allow-empty?


---
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-3494) GenerateTableFetch Some JDBC Drivers Have Trouble With Name vs Label

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15870781#comment-15870781
 ] 

ASF GitHub Bot commented on NIFI-3494:
--

GitHub user patricker opened a pull request:

https://github.com/apache/nifi/pull/1517

NIFI-3494 GenerateTableFetch Some JDBC Drivers Have Trouble With Name vs 
Label

A tiny change to support JDBC drivers that are too helpful.

### 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:
- [ ] Have you ensured that the full suite of tests is executed via mvn 
-Pcontrib-check clean install at the root nifi 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 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.


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/patricker/nifi NIFI-3494

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/nifi/pull/1517.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 #1517


commit 5d5b477deb1006188500a74065db0f11f720faaa
Author: patricker 
Date:   2017-02-16T21:41:21Z

NIFI-3494




> GenerateTableFetch Some JDBC Drivers Have Trouble With Name vs Label
> 
>
> Key: NIFI-3494
> URL: https://issues.apache.org/jira/browse/NIFI-3494
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.2.0
>Reporter: Peter Wicks
>Assignee: Peter Wicks
>Priority: Minor
> Fix For: 1.2.0
>
>
> When GenerateTableFetch retrieves the COUNT(*) and the Max Values for the 
> columns, some JDBC drivers (specifically SAP HANA) in this case have trouble 
> interpreting the name of the column if the "table" is actually a view.
> Since all max value columns are aliased with the original column name I'm 
> going to change the code to try Label first, and fall back to Name if it's 
> not there.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] nifi pull request #1517: NIFI-3494 GenerateTableFetch Some JDBC Drivers Have...

[patricker]

GitHub user patricker opened a pull request:

https://github.com/apache/nifi/pull/1517

NIFI-3494 GenerateTableFetch Some JDBC Drivers Have Trouble With Name vs 
Label

A tiny change to support JDBC drivers that are too helpful.

### 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:
- [ ] Have you ensured that the full suite of tests is executed via mvn 
-Pcontrib-check clean install at the root nifi 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 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.


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/patricker/nifi NIFI-3494

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/nifi/pull/1517.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 #1517


commit 5d5b477deb1006188500a74065db0f11f720faaa
Author: patricker 
Date:   2017-02-16T21:41:21Z

NIFI-3494




---
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-3494) GenerateTableFetch Some JDBC Drivers Have Trouble With Name vs Label

[Peter Wicks (JIRA)]

Peter Wicks created NIFI-3494:
-

 Summary: GenerateTableFetch Some JDBC Drivers Have Trouble With 
Name vs Label
 Key: NIFI-3494
 URL: https://issues.apache.org/jira/browse/NIFI-3494
 Project: Apache NiFi
  Issue Type: Bug
  Components: Core Framework
Affects Versions: 1.2.0
Reporter: Peter Wicks
Assignee: Peter Wicks
Priority: Minor
 Fix For: 1.2.0


When GenerateTableFetch retrieves the COUNT(*) and the Max Values for the 
columns, some JDBC drivers (specifically SAP HANA) in this case have trouble 
interpreting the name of the column if the "table" is actually a view.

Since all max value columns are aliased with the original column name I'm going 
to change the code to try Label first, and fall back to Name if it's not there.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (NIFI-3332) Bug in ListXXX causes matching timestamps to be ignored on later runs

[Michael Moser (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15870719#comment-15870719
 ] 

Michael Moser commented on NIFI-3332:
-

Is this related to NIFI-3213 at all?  Would be good to try the unit tests 
attached here on the fixed code provided in PR #1335

> Bug in ListXXX causes matching timestamps to be ignored on later runs
> -
>
> Key: NIFI-3332
> URL: https://issues.apache.org/jira/browse/NIFI-3332
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 0.7.1, 1.1.1
>Reporter: Joe Skora
>Priority: Critical
> Attachments: Test-showing-ListFile-timestamp-bug.log, 
> Test-showing-ListFile-timestamp-bug.patch
>
>
> The new state implementation for the ListXXX processors based on 
> AbstractListProcessor creates a race conditions when processor runs occur 
> while a batch of files is being written with the same timestamp.
> The changes to state management dropped tracking of the files processed for a 
> given timestamp.  Without the record of files processed, the remainder of the 
> batch is ignored on the next processor run since their timestamp is not 
> greater than the one timestamp stored in processor state.  With the file 
> tracking it was possible to process files that matched the timestamp exactly 
> and exclude the previously processed files.
> A basic time goes as follows.
>   T0 - system creates or receives batch of files with Tx timestamp where Tx 
> is more than the current timestamp in processor state.
>   T1 - system writes 1st half of Tx batch to the ListFile source directory.
>   T2 - ListFile runs picking up 1st half of Tx batch and stores Tx timestamp 
> in processor state.
>   T3 - system writes 2nd half of Tx batch to ListFile source directory.
>   T4 - ListFile runs ignoring any files with T <= Tx, eliminating 2nd half Tx 
> timestamp batch.
> I've attached a patch[1] for TestListFile.java that adds an instrumented unit 
> test demonstrates the problem and a log[2] of the output from one such run.  
> The test writes 3 files each in two batches with processor runs after each 
> batch.  Batch 2 writes files with timestamps older than, equal to, and newer 
> than the timestamp stored when batch 1 was processed, but only the newer file 
> is picked up.  The older file is correctly ignored but file with the matchin 
> timestamp file should have been processed.
> [1] Test-showing-ListFile-timestamp-bug.patch
> [2] Test-showing-ListFile-timestamp-bug.log



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] nifi issue #1016: NIFI-2724 New JMX Processor

[trixpan]

Github user trixpan commented on the issue:

https://github.com/apache/nifi/pull/1016
  
No no. Cherry pick your commit number. 

You will likely to fix conflicts in the process but  git will flag those 
files with conflict so once you fix it should be ok at the end


---
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-2724) JMX Processor

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15870688#comment-15870688
 ] 

ASF GitHub Bot commented on NIFI-2724:
--

Github user trixpan commented on the issue:

https://github.com/apache/nifi/pull/1016
  
Try

git checkout master -b nifi-2724v2
git cherry-pick your commit hash
git push - f origin nifi-2724

This will create a temporary branch
Allow you to copy a commit from another branch (cherry pick) and the force 
git to push to your original branch


> JMX Processor
> -
>
> Key: NIFI-2724
> URL: https://issues.apache.org/jira/browse/NIFI-2724
> Project: Apache NiFi
>  Issue Type: New Feature
>  Components: Extensions
>Affects Versions: 1.0.0
> Environment: All platforms with Java RMI support for JMX
>Reporter: Brian Burnett
>Assignee: Andre
>Priority: Minor
>  Labels: processor
> Attachments: 0001-NIFI-2724-New-JMX-Processor.patch
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> The JMX Processor feature addition includes only GetJMX without 
> SecurityManager capabilities at this time.  The processor in its current 
> state is capable of pulling MBean Property and Attribute values from a remote 
> RMI Server.  Each set of Mbean data is wrapped in a JSON formatted FlowFile 
> for downstream processing.  It has the ability to control content with 
> whitelist and blacklist properties.
> Possible use for this processor and the reason it was created is to help make 
> sense of Kafka server metrics.
> Will followup with a SecurityManager Context Service and PutJMX Processor.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (NIFI-2724) JMX Processor

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15870689#comment-15870689
 ] 

ASF GitHub Bot commented on NIFI-2724:
--

Github user brianburnett commented on the issue:

https://github.com/apache/nifi/pull/1016
  
Didn't your previous post. 

git cherry-pick master?


> JMX Processor
> -
>
> Key: NIFI-2724
> URL: https://issues.apache.org/jira/browse/NIFI-2724
> Project: Apache NiFi
>  Issue Type: New Feature
>  Components: Extensions
>Affects Versions: 1.0.0
> Environment: All platforms with Java RMI support for JMX
>Reporter: Brian Burnett
>Assignee: Andre
>Priority: Minor
>  Labels: processor
> Attachments: 0001-NIFI-2724-New-JMX-Processor.patch
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> The JMX Processor feature addition includes only GetJMX without 
> SecurityManager capabilities at this time.  The processor in its current 
> state is capable of pulling MBean Property and Attribute values from a remote 
> RMI Server.  Each set of Mbean data is wrapped in a JSON formatted FlowFile 
> for downstream processing.  It has the ability to control content with 
> whitelist and blacklist properties.
> Possible use for this processor and the reason it was created is to help make 
> sense of Kafka server metrics.
> Will followup with a SecurityManager Context Service and PutJMX Processor.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] nifi issue #1016: NIFI-2724 New JMX Processor

[brianburnett]

Github user brianburnett commented on the issue:

https://github.com/apache/nifi/pull/1016
  
Didn't your previous post. 

git cherry-pick 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.
---

[GitHub] nifi issue #1016: NIFI-2724 New JMX Processor

[trixpan]

Github user trixpan commented on the issue:

https://github.com/apache/nifi/pull/1016
  
Try

git checkout master -b nifi-2724v2
git cherry-pick your commit hash
git push - f origin nifi-2724

This will create a temporary branch
Allow you to copy a commit from another branch (cherry pick) and the force 
git to push to your original branch


---
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-3181) Add more options to right-click menu options when root process group is selected

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15870682#comment-15870682
 ] 

ASF GitHub Bot commented on NIFI-3181:
--

Github user mcgilman commented on the issue:

https://github.com/apache/nifi/pull/1516
  
Will review...


> Add more options to right-click menu options when root process group is 
> selected
> 
>
> Key: NIFI-3181
> URL: https://issues.apache.org/jira/browse/NIFI-3181
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core UI
>Reporter: Andrew Lim
>Assignee: Scott Aslan
>Priority: Minor
>
> When the root process group is selected, right-clicking on the canvas 
> provides "Refresh" as the only option.
> It would be very useful to add other menu selections.  At minimum, we should 
> add the selections available in the Operate Palette (Configure, Start, Stop, 
> Create Template, Upload Template).  This should greatly reduce the amount of 
> scrolling required if the user is actively in a part of the canvas that is 
> far away from the Operate Palette.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] nifi issue #1516: [NIFI-3181] add operate palette actions to context menu

[mcgilman]

Github user mcgilman commented on the issue:

https://github.com/apache/nifi/pull/1516
  
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-3360) Modularize canvas directory

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15870677#comment-15870677
 ] 

ASF GitHub Bot commented on NIFI-3360:
--

Github user asfgit closed the pull request at:

https://github.com/apache/nifi/pull/1506


> Modularize canvas directory
> ---
>
> Key: NIFI-3360
> URL: https://issues.apache.org/jira/browse/NIFI-3360
> Project: Apache NiFi
>  Issue Type: Sub-task
>  Components: Core UI
>Reporter: Scott Aslan
>Assignee: Scott Aslan
> Fix For: 1.2.0
>
>
> Need to modularize (re-package) UI components to promote maintainability and 
> eventual reusability for UI extensions. Components are already conceptually 
> modular however circular references exists which should not be allowed. Need 
> to re-package functions to eliminate circular
> references.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (NIFI-3360) Modularize canvas directory

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15870678#comment-15870678
 ] 

ASF GitHub Bot commented on NIFI-3360:
--

Github user mcgilman commented on the issue:

https://github.com/apache/nifi/pull/1506
  
Thanks @scottyaslan. This has been merged to master!


> Modularize canvas directory
> ---
>
> Key: NIFI-3360
> URL: https://issues.apache.org/jira/browse/NIFI-3360
> Project: Apache NiFi
>  Issue Type: Sub-task
>  Components: Core UI
>Reporter: Scott Aslan
>Assignee: Scott Aslan
> Fix For: 1.2.0
>
>
> Need to modularize (re-package) UI components to promote maintainability and 
> eventual reusability for UI extensions. Components are already conceptually 
> modular however circular references exists which should not be allowed. Need 
> to re-package functions to eliminate circular
> references.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] nifi issue #1506: [NIFI-3360] resolve clashing variable name for connection ...

[mcgilman]

Github user mcgilman commented on the issue:

https://github.com/apache/nifi/pull/1506
  
Thanks @scottyaslan. This has been merged 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.
---

[GitHub] nifi pull request #1506: [NIFI-3360] resolve clashing variable name for conn...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/nifi/pull/1506


---
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-3360) Modularize canvas directory

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15870676#comment-15870676
 ] 

ASF subversion and git services commented on NIFI-3360:
---

Commit d9828c240b87f36af7e3d9aefed753d4315f8b0a in nifi's branch 
refs/heads/master from [~scottyaslan]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=d9828c2 ]

[NIFI-3360] resolve clashing variable name for connection and nf.Connection. 
This closes #1506


> Modularize canvas directory
> ---
>
> Key: NIFI-3360
> URL: https://issues.apache.org/jira/browse/NIFI-3360
> Project: Apache NiFi
>  Issue Type: Sub-task
>  Components: Core UI
>Reporter: Scott Aslan
>Assignee: Scott Aslan
> Fix For: 1.2.0
>
>
> Need to modularize (re-package) UI components to promote maintainability and 
> eventual reusability for UI extensions. Components are already conceptually 
> modular however circular references exists which should not be allowed. Need 
> to re-package functions to eliminate circular
> references.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (NIFI-2724) JMX Processor

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15870670#comment-15870670
 ] 

ASF GitHub Bot commented on NIFI-2724:
--

Github user brianburnett commented on the issue:

https://github.com/apache/nifi/pull/1016
  
Dang - I have little git experience.  Know the best way to move forward 
from here?


> JMX Processor
> -
>
> Key: NIFI-2724
> URL: https://issues.apache.org/jira/browse/NIFI-2724
> Project: Apache NiFi
>  Issue Type: New Feature
>  Components: Extensions
>Affects Versions: 1.0.0
> Environment: All platforms with Java RMI support for JMX
>Reporter: Brian Burnett
>Assignee: Andre
>Priority: Minor
>  Labels: processor
> Attachments: 0001-NIFI-2724-New-JMX-Processor.patch
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> The JMX Processor feature addition includes only GetJMX without 
> SecurityManager capabilities at this time.  The processor in its current 
> state is capable of pulling MBean Property and Attribute values from a remote 
> RMI Server.  Each set of Mbean data is wrapped in a JSON formatted FlowFile 
> for downstream processing.  It has the ability to control content with 
> whitelist and blacklist properties.
> Possible use for this processor and the reason it was created is to help make 
> sense of Kafka server metrics.
> Will followup with a SecurityManager Context Service and PutJMX Processor.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] nifi issue #1016: NIFI-2724 New JMX Processor

[brianburnett]

Github user brianburnett commented on the issue:

https://github.com/apache/nifi/pull/1016
  
Dang - I have little git experience.  Know the best way to move forward 
from here?


---
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-2724) JMX Processor

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15870668#comment-15870668
 ] 

ASF GitHub Bot commented on NIFI-2724:
--

Github user trixpan commented on the issue:

https://github.com/apache/nifi/pull/1016
  
Try

git checkout master -b nifi-2724v2
git cherry-pick 
git push origin nifi-2724


> JMX Processor
> -
>
> Key: NIFI-2724
> URL: https://issues.apache.org/jira/browse/NIFI-2724
> Project: Apache NiFi
>  Issue Type: New Feature
>  Components: Extensions
>Affects Versions: 1.0.0
> Environment: All platforms with Java RMI support for JMX
>Reporter: Brian Burnett
>Assignee: Andre
>Priority: Minor
>  Labels: processor
> Attachments: 0001-NIFI-2724-New-JMX-Processor.patch
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> The JMX Processor feature addition includes only GetJMX without 
> SecurityManager capabilities at this time.  The processor in its current 
> state is capable of pulling MBean Property and Attribute values from a remote 
> RMI Server.  Each set of Mbean data is wrapped in a JSON formatted FlowFile 
> for downstream processing.  It has the ability to control content with 
> whitelist and blacklist properties.
> Possible use for this processor and the reason it was created is to help make 
> sense of Kafka server metrics.
> Will followup with a SecurityManager Context Service and PutJMX Processor.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] nifi issue #1016: NIFI-2724 New JMX Processor

[trixpan]

Github user trixpan commented on the issue:

https://github.com/apache/nifi/pull/1016
  
Try

git checkout master -b nifi-2724v2
git cherry-pick 
git push origin nifi-2724


---
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-2724) JMX Processor

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15870660#comment-15870660
 ] 

ASF GitHub Bot commented on NIFI-2724:
--

Github user trixpan commented on the issue:

https://github.com/apache/nifi/pull/1016
  
That was a merge, not a rebase :-(




> JMX Processor
> -
>
> Key: NIFI-2724
> URL: https://issues.apache.org/jira/browse/NIFI-2724
> Project: Apache NiFi
>  Issue Type: New Feature
>  Components: Extensions
>Affects Versions: 1.0.0
> Environment: All platforms with Java RMI support for JMX
>Reporter: Brian Burnett
>Assignee: Andre
>Priority: Minor
>  Labels: processor
> Attachments: 0001-NIFI-2724-New-JMX-Processor.patch
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> The JMX Processor feature addition includes only GetJMX without 
> SecurityManager capabilities at this time.  The processor in its current 
> state is capable of pulling MBean Property and Attribute values from a remote 
> RMI Server.  Each set of Mbean data is wrapped in a JSON formatted FlowFile 
> for downstream processing.  It has the ability to control content with 
> whitelist and blacklist properties.
> Possible use for this processor and the reason it was created is to help make 
> sense of Kafka server metrics.
> Will followup with a SecurityManager Context Service and PutJMX Processor.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] nifi issue #1016: NIFI-2724 New JMX Processor

[trixpan]

Github user trixpan commented on the issue:

https://github.com/apache/nifi/pull/1016
  
That was a merge, not a rebase :-(




---
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-2724) JMX Processor

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15870639#comment-15870639
 ] 

ASF GitHub Bot commented on NIFI-2724:
--

Github user brianburnett commented on the issue:

https://github.com/apache/nifi/pull/1016
  
Rebased - jumped through some git hoops but I believe it is current.  Let 
me know. Thanks


> JMX Processor
> -
>
> Key: NIFI-2724
> URL: https://issues.apache.org/jira/browse/NIFI-2724
> Project: Apache NiFi
>  Issue Type: New Feature
>  Components: Extensions
>Affects Versions: 1.0.0
> Environment: All platforms with Java RMI support for JMX
>Reporter: Brian Burnett
>Assignee: Andre
>Priority: Minor
>  Labels: processor
> Attachments: 0001-NIFI-2724-New-JMX-Processor.patch
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> The JMX Processor feature addition includes only GetJMX without 
> SecurityManager capabilities at this time.  The processor in its current 
> state is capable of pulling MBean Property and Attribute values from a remote 
> RMI Server.  Each set of Mbean data is wrapped in a JSON formatted FlowFile 
> for downstream processing.  It has the ability to control content with 
> whitelist and blacklist properties.
> Possible use for this processor and the reason it was created is to help make 
> sense of Kafka server metrics.
> Will followup with a SecurityManager Context Service and PutJMX Processor.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] nifi issue #1016: NIFI-2724 New JMX Processor

[brianburnett]

Github user brianburnett commented on the issue:

https://github.com/apache/nifi/pull/1016
  
Rebased - jumped through some git hoops but I believe it is current.  Let 
me know. Thanks


---
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-3354) Create CSV To Avro transformer

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15870529#comment-15870529
 ] 

ASF GitHub Bot commented on NIFI-3354:
--

Github user joewitt commented on the issue:

https://github.com/apache/nifi/pull/1436
  
OK - so these processors should support input data with multiple events.  
Going from CSV to JSON should allow CSV input to have multiple rows and it 
would output an array of JSON objects.  Going from CSV to Avro should do the 
same but in avro friendly way.  Etc.. This avoids the need for splitting cases.

Can you please raise a JIRA to address this/improve this later?  I think 
as-is this is quite useful.  Please address the licensing concern and I'll take 
another look.  If that is sorted I'm a +1 and will merge (please squash the 
last commits with the licensing fix.

thanks!


> Create CSV To Avro transformer
> --
>
> Key: NIFI-3354
> URL: https://issues.apache.org/jira/browse/NIFI-3354
> Project: Apache NiFi
>  Issue Type: Sub-task
>Reporter: Oleg Zhurakousky
>Assignee: Oleg Zhurakousky
> Fix For: 1.2.0
>
> Attachments: csv_content.txt, NIFI-3354.xml
>
>
> While we currently have CSV to AVRO transformer it required HDFS/Kite 
> dependencies which could be easily eliminated.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] nifi issue #1436: NIFI-3354 Added support for simple AVRO/CSV/JSON transform...

[joewitt]

Github user joewitt commented on the issue:

https://github.com/apache/nifi/pull/1436
  
OK - so these processors should support input data with multiple events.  
Going from CSV to JSON should allow CSV input to have multiple rows and it 
would output an array of JSON objects.  Going from CSV to Avro should do the 
same but in avro friendly way.  Etc.. This avoids the need for splitting cases.

Can you please raise a JIRA to address this/improve this later?  I think 
as-is this is quite useful.  Please address the licensing concern and I'll take 
another look.  If that is sorted I'm a +1 and will merge (please squash the 
last commits with the licensing fix.

thanks!


---
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-3181) Add more options to right-click menu options when root process group is selected

[Scott Aslan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-3181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Scott Aslan updated NIFI-3181:
--
Status: Patch Available  (was: In Progress)

> Add more options to right-click menu options when root process group is 
> selected
> 
>
> Key: NIFI-3181
> URL: https://issues.apache.org/jira/browse/NIFI-3181
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core UI
>Reporter: Andrew Lim
>Assignee: Scott Aslan
>Priority: Minor
>
> When the root process group is selected, right-clicking on the canvas 
> provides "Refresh" as the only option.
> It would be very useful to add other menu selections.  At minimum, we should 
> add the selections available in the Operate Palette (Configure, Start, Stop, 
> Create Template, Upload Template).  This should greatly reduce the amount of 
> scrolling required if the user is actively in a part of the canvas that is 
> far away from the Operate Palette.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (NIFI-3181) Add more options to right-click menu options when root process group is selected

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15870521#comment-15870521
 ] 

ASF GitHub Bot commented on NIFI-3181:
--

GitHub user scottyaslan opened a pull request:

https://github.com/apache/nifi/pull/1516

[NIFI-3181] add operate palette actions to context menu

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:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced 
 in the commit message?

- [ ] Does your PR title start with NIFI- where  is the JIRA number 
you are trying to resolve? Pay particular attention to the hyphen "-" character.

- [ ] Has your PR been rebased against the latest commit within the target 
branch (typically master)?

- [ ] Is your initial contribution a single, squashed commit?

### For code changes:
- [ ] Have you ensured that the full suite of tests is executed via mvn 
-Pcontrib-check clean install at the root nifi 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 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.


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/scottyaslan/nifi NIFI-3181

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/nifi/pull/1516.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 #1516


commit b3d4e45484f84dfde4ba5bc7cb27619ef6691ee7
Author: Scott Aslan 
Date:   2017-02-13T19:58:05Z

[NIFI-3181] add operate palette actions to context menu




> Add more options to right-click menu options when root process group is 
> selected
> 
>
> Key: NIFI-3181
> URL: https://issues.apache.org/jira/browse/NIFI-3181
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core UI
>Reporter: Andrew Lim
>Assignee: Scott Aslan
>Priority: Minor
>
> When the root process group is selected, right-clicking on the canvas 
> provides "Refresh" as the only option.
> It would be very useful to add other menu selections.  At minimum, we should 
> add the selections available in the Operate Palette (Configure, Start, Stop, 
> Create Template, Upload Template).  This should greatly reduce the amount of 
> scrolling required if the user is actively in a part of the canvas that is 
> far away from the Operate Palette.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] nifi pull request #1516: [NIFI-3181] add operate palette actions to context ...

[scottyaslan]

GitHub user scottyaslan opened a pull request:

https://github.com/apache/nifi/pull/1516

[NIFI-3181] add operate palette actions to context menu

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:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced 
 in the commit message?

- [ ] Does your PR title start with NIFI- where  is the JIRA number 
you are trying to resolve? Pay particular attention to the hyphen "-" character.

- [ ] Has your PR been rebased against the latest commit within the target 
branch (typically master)?

- [ ] Is your initial contribution a single, squashed commit?

### For code changes:
- [ ] Have you ensured that the full suite of tests is executed via mvn 
-Pcontrib-check clean install at the root nifi 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 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.


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/scottyaslan/nifi NIFI-3181

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/nifi/pull/1516.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 #1516


commit b3d4e45484f84dfde4ba5bc7cb27619ef6691ee7
Author: Scott Aslan 
Date:   2017-02-13T19:58:05Z

[NIFI-3181] add operate palette actions to context menu




---
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-3354) Create CSV To Avro transformer

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15870516#comment-15870516
 ] 

ASF GitHub Bot commented on NIFI-3354:
--

Github user joewitt commented on the issue:

https://github.com/apache/nifi/pull/1436
  
Oleg

the license/notice of the nar needs to cover

avro/jackson/commons compress/paranamer/snappy

All of these already elsewhere in license/notice as needed so should be a 
simple copy/paste.


> Create CSV To Avro transformer
> --
>
> Key: NIFI-3354
> URL: https://issues.apache.org/jira/browse/NIFI-3354
> Project: Apache NiFi
>  Issue Type: Sub-task
>Reporter: Oleg Zhurakousky
>Assignee: Oleg Zhurakousky
> Fix For: 1.2.0
>
> Attachments: csv_content.txt, NIFI-3354.xml
>
>
> While we currently have CSV to AVRO transformer it required HDFS/Kite 
> dependencies which could be easily eliminated.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] nifi issue #1436: NIFI-3354 Added support for simple AVRO/CSV/JSON transform...

[joewitt]

Github user joewitt commented on the issue:

https://github.com/apache/nifi/pull/1436
  
Oleg

the license/notice of the nar needs to cover

avro/jackson/commons compress/paranamer/snappy

All of these already elsewhere in license/notice as needed so should be a 
simple copy/paste.


---
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-3354) Create CSV To Avro transformer

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15870506#comment-15870506
 ] 

ASF GitHub Bot commented on NIFI-3354:
--

Github user joewitt commented on the issue:

https://github.com/apache/nifi/pull/1436
  
ok much better now that the hadoop stuff is out.  if that is necessary it 
could be added as a seperate nar which has this one as its parent.  Glad the 
extractschema is gone.  Will test again and respond.  thanks


> Create CSV To Avro transformer
> --
>
> Key: NIFI-3354
> URL: https://issues.apache.org/jira/browse/NIFI-3354
> Project: Apache NiFi
>  Issue Type: Sub-task
>Reporter: Oleg Zhurakousky
>Assignee: Oleg Zhurakousky
> Fix For: 1.2.0
>
> Attachments: csv_content.txt, NIFI-3354.xml
>
>
> While we currently have CSV to AVRO transformer it required HDFS/Kite 
> dependencies which could be easily eliminated.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] nifi issue #1436: NIFI-3354 Added support for simple AVRO/CSV/JSON transform...

[joewitt]

Github user joewitt commented on the issue:

https://github.com/apache/nifi/pull/1436
  
ok much better now that the hadoop stuff is out.  if that is necessary it 
could be added as a seperate nar which has this one as its parent.  Glad the 
extractschema is gone.  Will test again and respond.  thanks


---
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] [Resolved] (NIFI-3493) Security configuration section in Admin Guide incorrectly refers to nifi.web.http.network.interface instead of nifi.web.https.network.interface

[Bryan Rosander (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-3493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bryan Rosander resolved NIFI-3493.
--
   Resolution: Fixed
Fix Version/s: 1.2.0

> Security configuration section in Admin Guide incorrectly refers to 
> nifi.web.http.network.interface instead of nifi.web.https.network.interface
> ---
>
> Key: NIFI-3493
> URL: https://issues.apache.org/jira/browse/NIFI-3493
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Documentation & Website
>Affects Versions: 1.2.0
>Reporter: Andrew Lim
>Assignee: Andrew Lim
>Priority: Minor
> Fix For: 1.2.0
>
>
> Here is the reference in the Admin Guide:
> "To allow admins to configure the application to run only on specific network 
> interfaces, nifi.web.http.network.interface* or 
> nifi.web.http.network.interface* properties can be specified."
> The second property should refer to HTTPS:  nifi.web.https.network.interface*



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (NIFI-3493) Security configuration section in Admin Guide incorrectly refers to nifi.web.http.network.interface instead of nifi.web.https.network.interface

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15870409#comment-15870409
 ] 

ASF subversion and git services commented on NIFI-3493:
---

Commit 855743f9333f1eb16a24d271b3222a84999ea0b2 in nifi's branch 
refs/heads/master from [~andrewmlim]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=855743f ]

NIFI-3493 Corrected reference in Admin Guide to http not https for 
nifi.web.https.network.interface property

This closes #1515.

Signed-off-by: Bryan Rosander 


> Security configuration section in Admin Guide incorrectly refers to 
> nifi.web.http.network.interface instead of nifi.web.https.network.interface
> ---
>
> Key: NIFI-3493
> URL: https://issues.apache.org/jira/browse/NIFI-3493
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Documentation & Website
>Affects Versions: 1.2.0
>Reporter: Andrew Lim
>Assignee: Andrew Lim
>Priority: Minor
>
> Here is the reference in the Admin Guide:
> "To allow admins to configure the application to run only on specific network 
> interfaces, nifi.web.http.network.interface* or 
> nifi.web.http.network.interface* properties can be specified."
> The second property should refer to HTTPS:  nifi.web.https.network.interface*



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (NIFI-3493) Security configuration section in Admin Guide incorrectly refers to nifi.web.http.network.interface instead of nifi.web.https.network.interface

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15870411#comment-15870411
 ] 

ASF GitHub Bot commented on NIFI-3493:
--

Github user asfgit closed the pull request at:

https://github.com/apache/nifi/pull/1515


> Security configuration section in Admin Guide incorrectly refers to 
> nifi.web.http.network.interface instead of nifi.web.https.network.interface
> ---
>
> Key: NIFI-3493
> URL: https://issues.apache.org/jira/browse/NIFI-3493
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Documentation & Website
>Affects Versions: 1.2.0
>Reporter: Andrew Lim
>Assignee: Andrew Lim
>Priority: Minor
>
> Here is the reference in the Admin Guide:
> "To allow admins to configure the application to run only on specific network 
> interfaces, nifi.web.http.network.interface* or 
> nifi.web.http.network.interface* properties can be specified."
> The second property should refer to HTTPS:  nifi.web.https.network.interface*



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] nifi pull request #1515: NIFI-3493 Corrected reference in Admin Guide to htt...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/nifi/pull/1515


---
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-3493) Security configuration section in Admin Guide incorrectly refers to nifi.web.http.network.interface instead of nifi.web.https.network.interface

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15870301#comment-15870301
 ] 

ASF GitHub Bot commented on NIFI-3493:
--

GitHub user andrewmlim opened a pull request:

https://github.com/apache/nifi/pull/1515

NIFI-3493 Corrected reference in Admin Guide to http not https for ni…

…fi.web.https.network.interface property

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/andrewmlim/nifi NIFI-3493

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/nifi/pull/1515.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 #1515


commit b39af3f4046b0bae8b01da8d8310cfeda44a7713
Author: Andrew Lim 
Date:   2017-02-16T17:10:37Z

NIFI-3493 Corrected reference in Admin Guide to http not https for 
nifi.web.https.network.interface property




> Security configuration section in Admin Guide incorrectly refers to 
> nifi.web.http.network.interface instead of nifi.web.https.network.interface
> ---
>
> Key: NIFI-3493
> URL: https://issues.apache.org/jira/browse/NIFI-3493
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Documentation & Website
>Affects Versions: 1.2.0
>Reporter: Andrew Lim
>Assignee: Andrew Lim
>Priority: Minor
>
> Here is the reference in the Admin Guide:
> "To allow admins to configure the application to run only on specific network 
> interfaces, nifi.web.http.network.interface* or 
> nifi.web.http.network.interface* properties can be specified."
> The second property should refer to HTTPS:  nifi.web.https.network.interface*



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] nifi pull request #1515: NIFI-3493 Corrected reference in Admin Guide to htt...

[andrewmlim]

GitHub user andrewmlim opened a pull request:

https://github.com/apache/nifi/pull/1515

NIFI-3493 Corrected reference in Admin Guide to http not https for ni…

…fi.web.https.network.interface property

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/andrewmlim/nifi NIFI-3493

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/nifi/pull/1515.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 #1515


commit b39af3f4046b0bae8b01da8d8310cfeda44a7713
Author: Andrew Lim 
Date:   2017-02-16T17:10:37Z

NIFI-3493 Corrected reference in Admin Guide to http not https for 
nifi.web.https.network.interface property




---
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-3493) Security configuration section in Admin Guide incorrectly refers to nifi.web.http.network.interface instead of nifi.web.https.network.interface

[Andrew Lim (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-3493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Lim updated NIFI-3493:
-
Description: 
Here is the reference in the Admin Guide:

"To allow admins to configure the application to run only on specific network 
interfaces, nifi.web.http.network.interface* or 
nifi.web.http.network.interface* properties can be specified."

The second property should refer to HTTPS:  nifi.web.https.network.interface*

  was:
Here is the reference in the Admin Guide:

To allow admins to configure the application to run only on specific network 
interfaces, nifi.web.http.network.interface* or 
nifi.web.http.network.interface* properties can be specified.

The second property should refer to HTTPS:  nifi.web.https.network.interface*


> Security configuration section in Admin Guide incorrectly refers to 
> nifi.web.http.network.interface instead of nifi.web.https.network.interface
> ---
>
> Key: NIFI-3493
> URL: https://issues.apache.org/jira/browse/NIFI-3493
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Documentation & Website
>Affects Versions: 1.2.0
>Reporter: Andrew Lim
>Assignee: Andrew Lim
>Priority: Minor
>
> Here is the reference in the Admin Guide:
> "To allow admins to configure the application to run only on specific network 
> interfaces, nifi.web.http.network.interface* or 
> nifi.web.http.network.interface* properties can be specified."
> The second property should refer to HTTPS:  nifi.web.https.network.interface*



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (NIFI-3493) Security configuration section in Admin Guide incorrectly refers to nifi.web.http.network.interface instead of nifi.web.https.network.interface

[Andrew Lim (JIRA)]

Andrew Lim created NIFI-3493:


 Summary: Security configuration section in Admin Guide incorrectly 
refers to nifi.web.http.network.interface instead of 
nifi.web.https.network.interface
 Key: NIFI-3493
 URL: https://issues.apache.org/jira/browse/NIFI-3493
 Project: Apache NiFi
  Issue Type: Bug
  Components: Documentation & Website
Affects Versions: 1.2.0
Reporter: Andrew Lim
Priority: Minor


Here is the reference in the Admin Guide:

To allow admins to configure the application to run only on specific network 
interfaces, nifi.web.http.network.interface* or 
nifi.web.http.network.interface* properties can be specified.

The second property should refer to HTTPS:  nifi.web.https.network.interface*



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (NIFI-3493) Security configuration section in Admin Guide incorrectly refers to nifi.web.http.network.interface instead of nifi.web.https.network.interface

[Andrew Lim (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-3493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Lim reassigned NIFI-3493:


Assignee: Andrew Lim

> Security configuration section in Admin Guide incorrectly refers to 
> nifi.web.http.network.interface instead of nifi.web.https.network.interface
> ---
>
> Key: NIFI-3493
> URL: https://issues.apache.org/jira/browse/NIFI-3493
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Documentation & Website
>Affects Versions: 1.2.0
>Reporter: Andrew Lim
>Assignee: Andrew Lim
>Priority: Minor
>
> Here is the reference in the Admin Guide:
> To allow admins to configure the application to run only on specific network 
> interfaces, nifi.web.http.network.interface* or 
> nifi.web.http.network.interface* properties can be specified.
> The second property should refer to HTTPS:  nifi.web.https.network.interface*



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (NIFI-3492) Allow configuration of default back pressure

[Brandon DeVries (JIRA)]

Brandon DeVries created NIFI-3492:
-

 Summary: Allow configuration of default back pressure
 Key: NIFI-3492
 URL: https://issues.apache.org/jira/browse/NIFI-3492
 Project: Apache NiFi
  Issue Type: Improvement
Affects Versions: 1.1.1
Reporter: Brandon DeVries


NiFi 1.x sets a default back pressure of 10K files / 1 GB instead of the 
"unlimited" default in 0.x.  This is better in a lot of ways... however those 
values are potentially a bit arbitrary, and not appropriate for every system.  

These values should be configurable, and exposed in nifi.properties.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (NIFI-3150) ZooKeeper Migrator does not wait for connection before attempting to read/write to ZooKeeper

[Jeff Storck (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-3150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeff Storck updated NIFI-3150:
--
Fix Version/s: 1.1.0

> ZooKeeper Migrator does not wait for connection before attempting to 
> read/write to ZooKeeper
> 
>
> Key: NIFI-3150
> URL: https://issues.apache.org/jira/browse/NIFI-3150
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Tools and Build
>Affects Versions: 1.1.0
>Reporter: Jeff Storck
>Assignee: Jeff Storck
> Fix For: 1.1.0
>
>
> While running NiFi in a 3-node cluster, attempting to read or write ZK data 
> to the ZK ensemble results in intermittent connection loss exceptions because 
> the migrator is not waiting for the asynchronous connection method in ZK to 
> report that the client has completely connected.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (NIFI-3480) Fix incorrect Admin Guide documentation regarding anonymous access

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15870071#comment-15870071
 ] 

ASF GitHub Bot commented on NIFI-3480:
--

Github user asfgit closed the pull request at:

https://github.com/apache/nifi/pull/1512


> Fix incorrect Admin Guide documentation regarding anonymous access
> --
>
> Key: NIFI-3480
> URL: https://issues.apache.org/jira/browse/NIFI-3480
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Documentation & Website
>Affects Versions: 1.1.1
>Reporter: Andy LoPresto
>Assignee: Andrew Lim
>Priority: Trivial
>  Labels: documentation, security
>
> The Admin Guide *Security Configuration* section states
> {quote}
> {{nifi.security.truststore}}
> Filename of the Truststore that will be used to authorize those connecting to 
> NiFi. If not set, all who attempt to connect will be provided access as the 
> *Anonymous* user.
> {quote}
> This is incorrect and misleading. The only way to configure a secured 
> instance with anonymous access is via LDAP or Kerberos and configuration of 
> the authorizer to explicitly allow anonymous access. Configuring a secured 
> instance with no truststore will simply refuse all incoming connections. 
> With {{nifi.security.needClientAuth}} set to {{true}} or empty (default):
> {code}
> 2017-02-14 12:03:05,546 WARN [Thread-1] 
> org.apache.nifi.web.server.JettyServer Failed to stop web server
> org.springframework.beans.factory.BeanCreationException: Error creating bean 
> with name 'flowService': FactoryBean threw exception on object creation; 
> nested exception is org.springframework.beans.factory.BeanCreationException: 
> Error creating bean with name 'flowController': FactoryBean threw exception 
> on object creation; nested exception is 
> org.apache.nifi.framework.security.util.SslContextCreationException: Need 
> client auth is set to 'true', but no truststore properties are configured.
>   at 
> org.springframework.beans.factory.support.FactoryBeanRegistrySupport.doGetObjectFromFactoryBean(FactoryBeanRegistrySupport.java:175)
>  ~[na:na]
>   at 
> org.springframework.beans.factory.support.FactoryBeanRegistrySupport.getObjectFromFactoryBean(FactoryBeanRegistrySupport.java:103)
>  ~[na:na]
>   at 
> org.springframework.beans.factory.support.AbstractBeanFactory.getObjectForBeanInstance(AbstractBeanFactory.java:1585)
>  ~[na:na]
>   at 
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:254)
>  ~[na:na]
>   at 
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:202)
>  ~[na:na]
>   at 
> org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:1060)
>  ~[na:na]
>   at 
> org.apache.nifi.web.contextlistener.ApplicationStartupContextListener.contextDestroyed(ApplicationStartupContextListener.java:103)
>  ~[na:na]
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.callContextDestroyed(ContextHandler.java:845)
>  ~[na:na]
>   at 
> org.eclipse.jetty.servlet.ServletContextHandler.callContextDestroyed(ServletContextHandler.java:546)
>  ~[na:na]
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.stopContext(ContextHandler.java:826)
>  ~[na:na]
>   at 
> org.eclipse.jetty.servlet.ServletContextHandler.stopContext(ServletContextHandler.java:356)
>  ~[na:na]
>   at 
> org.eclipse.jetty.webapp.WebAppContext.stopWebapp(WebAppContext.java:1410) 
> ~[na:na]
>   at 
> org.eclipse.jetty.webapp.WebAppContext.stopContext(WebAppContext.java:1374) 
> ~[na:na]
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doStop(ContextHandler.java:874)
>  ~[na:na]
>   at 
> org.eclipse.jetty.servlet.ServletContextHandler.doStop(ServletContextHandler.java:272)
>  ~[na:na]
>   at 
> org.eclipse.jetty.webapp.WebAppContext.doStop(WebAppContext.java:544) ~[na:na]
>   at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
>  ~[na:na]
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:143)
>  ~[na:na]
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:161)
>  ~[na:na]
>   at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStop(AbstractHandler.java:73)
>  ~[na:na]
>   at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
>  ~[na:na]
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:143)
>  ~[na:na]
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:161)
>  ~[na:na]
>   at 
> 

[jira] [Commented] (NIFI-3480) Fix incorrect Admin Guide documentation regarding anonymous access

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15870072#comment-15870072
 ] 

ASF GitHub Bot commented on NIFI-3480:
--

Github user scottyaslan commented on the issue:

https://github.com/apache/nifi/pull/1512
  
Thanks @andrewmlim this has been merged to master.


> Fix incorrect Admin Guide documentation regarding anonymous access
> --
>
> Key: NIFI-3480
> URL: https://issues.apache.org/jira/browse/NIFI-3480
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Documentation & Website
>Affects Versions: 1.1.1
>Reporter: Andy LoPresto
>Assignee: Andrew Lim
>Priority: Trivial
>  Labels: documentation, security
>
> The Admin Guide *Security Configuration* section states
> {quote}
> {{nifi.security.truststore}}
> Filename of the Truststore that will be used to authorize those connecting to 
> NiFi. If not set, all who attempt to connect will be provided access as the 
> *Anonymous* user.
> {quote}
> This is incorrect and misleading. The only way to configure a secured 
> instance with anonymous access is via LDAP or Kerberos and configuration of 
> the authorizer to explicitly allow anonymous access. Configuring a secured 
> instance with no truststore will simply refuse all incoming connections. 
> With {{nifi.security.needClientAuth}} set to {{true}} or empty (default):
> {code}
> 2017-02-14 12:03:05,546 WARN [Thread-1] 
> org.apache.nifi.web.server.JettyServer Failed to stop web server
> org.springframework.beans.factory.BeanCreationException: Error creating bean 
> with name 'flowService': FactoryBean threw exception on object creation; 
> nested exception is org.springframework.beans.factory.BeanCreationException: 
> Error creating bean with name 'flowController': FactoryBean threw exception 
> on object creation; nested exception is 
> org.apache.nifi.framework.security.util.SslContextCreationException: Need 
> client auth is set to 'true', but no truststore properties are configured.
>   at 
> org.springframework.beans.factory.support.FactoryBeanRegistrySupport.doGetObjectFromFactoryBean(FactoryBeanRegistrySupport.java:175)
>  ~[na:na]
>   at 
> org.springframework.beans.factory.support.FactoryBeanRegistrySupport.getObjectFromFactoryBean(FactoryBeanRegistrySupport.java:103)
>  ~[na:na]
>   at 
> org.springframework.beans.factory.support.AbstractBeanFactory.getObjectForBeanInstance(AbstractBeanFactory.java:1585)
>  ~[na:na]
>   at 
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:254)
>  ~[na:na]
>   at 
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:202)
>  ~[na:na]
>   at 
> org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:1060)
>  ~[na:na]
>   at 
> org.apache.nifi.web.contextlistener.ApplicationStartupContextListener.contextDestroyed(ApplicationStartupContextListener.java:103)
>  ~[na:na]
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.callContextDestroyed(ContextHandler.java:845)
>  ~[na:na]
>   at 
> org.eclipse.jetty.servlet.ServletContextHandler.callContextDestroyed(ServletContextHandler.java:546)
>  ~[na:na]
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.stopContext(ContextHandler.java:826)
>  ~[na:na]
>   at 
> org.eclipse.jetty.servlet.ServletContextHandler.stopContext(ServletContextHandler.java:356)
>  ~[na:na]
>   at 
> org.eclipse.jetty.webapp.WebAppContext.stopWebapp(WebAppContext.java:1410) 
> ~[na:na]
>   at 
> org.eclipse.jetty.webapp.WebAppContext.stopContext(WebAppContext.java:1374) 
> ~[na:na]
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doStop(ContextHandler.java:874)
>  ~[na:na]
>   at 
> org.eclipse.jetty.servlet.ServletContextHandler.doStop(ServletContextHandler.java:272)
>  ~[na:na]
>   at 
> org.eclipse.jetty.webapp.WebAppContext.doStop(WebAppContext.java:544) ~[na:na]
>   at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
>  ~[na:na]
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:143)
>  ~[na:na]
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:161)
>  ~[na:na]
>   at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStop(AbstractHandler.java:73)
>  ~[na:na]
>   at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
>  ~[na:na]
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:143)
>  ~[na:na]
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:161)
>  

[jira] [Resolved] (NIFI-3480) Fix incorrect Admin Guide documentation regarding anonymous access

[Scott Aslan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-3480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Scott Aslan resolved NIFI-3480.
---
Resolution: Fixed

> Fix incorrect Admin Guide documentation regarding anonymous access
> --
>
> Key: NIFI-3480
> URL: https://issues.apache.org/jira/browse/NIFI-3480
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Documentation & Website
>Affects Versions: 1.1.1
>Reporter: Andy LoPresto
>Assignee: Andrew Lim
>Priority: Trivial
>  Labels: documentation, security
>
> The Admin Guide *Security Configuration* section states
> {quote}
> {{nifi.security.truststore}}
> Filename of the Truststore that will be used to authorize those connecting to 
> NiFi. If not set, all who attempt to connect will be provided access as the 
> *Anonymous* user.
> {quote}
> This is incorrect and misleading. The only way to configure a secured 
> instance with anonymous access is via LDAP or Kerberos and configuration of 
> the authorizer to explicitly allow anonymous access. Configuring a secured 
> instance with no truststore will simply refuse all incoming connections. 
> With {{nifi.security.needClientAuth}} set to {{true}} or empty (default):
> {code}
> 2017-02-14 12:03:05,546 WARN [Thread-1] 
> org.apache.nifi.web.server.JettyServer Failed to stop web server
> org.springframework.beans.factory.BeanCreationException: Error creating bean 
> with name 'flowService': FactoryBean threw exception on object creation; 
> nested exception is org.springframework.beans.factory.BeanCreationException: 
> Error creating bean with name 'flowController': FactoryBean threw exception 
> on object creation; nested exception is 
> org.apache.nifi.framework.security.util.SslContextCreationException: Need 
> client auth is set to 'true', but no truststore properties are configured.
>   at 
> org.springframework.beans.factory.support.FactoryBeanRegistrySupport.doGetObjectFromFactoryBean(FactoryBeanRegistrySupport.java:175)
>  ~[na:na]
>   at 
> org.springframework.beans.factory.support.FactoryBeanRegistrySupport.getObjectFromFactoryBean(FactoryBeanRegistrySupport.java:103)
>  ~[na:na]
>   at 
> org.springframework.beans.factory.support.AbstractBeanFactory.getObjectForBeanInstance(AbstractBeanFactory.java:1585)
>  ~[na:na]
>   at 
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:254)
>  ~[na:na]
>   at 
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:202)
>  ~[na:na]
>   at 
> org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:1060)
>  ~[na:na]
>   at 
> org.apache.nifi.web.contextlistener.ApplicationStartupContextListener.contextDestroyed(ApplicationStartupContextListener.java:103)
>  ~[na:na]
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.callContextDestroyed(ContextHandler.java:845)
>  ~[na:na]
>   at 
> org.eclipse.jetty.servlet.ServletContextHandler.callContextDestroyed(ServletContextHandler.java:546)
>  ~[na:na]
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.stopContext(ContextHandler.java:826)
>  ~[na:na]
>   at 
> org.eclipse.jetty.servlet.ServletContextHandler.stopContext(ServletContextHandler.java:356)
>  ~[na:na]
>   at 
> org.eclipse.jetty.webapp.WebAppContext.stopWebapp(WebAppContext.java:1410) 
> ~[na:na]
>   at 
> org.eclipse.jetty.webapp.WebAppContext.stopContext(WebAppContext.java:1374) 
> ~[na:na]
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doStop(ContextHandler.java:874)
>  ~[na:na]
>   at 
> org.eclipse.jetty.servlet.ServletContextHandler.doStop(ServletContextHandler.java:272)
>  ~[na:na]
>   at 
> org.eclipse.jetty.webapp.WebAppContext.doStop(WebAppContext.java:544) ~[na:na]
>   at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
>  ~[na:na]
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:143)
>  ~[na:na]
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:161)
>  ~[na:na]
>   at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStop(AbstractHandler.java:73)
>  ~[na:na]
>   at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
>  ~[na:na]
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:143)
>  ~[na:na]
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:161)
>  ~[na:na]
>   at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStop(AbstractHandler.java:73)
>  ~[na:na]
>   at 
> 

[GitHub] nifi issue #1512: NIFI-3480 Fix incorrect Admin Guide documentation regardin...

[scottyaslan]

Github user scottyaslan commented on the issue:

https://github.com/apache/nifi/pull/1512
  
Thanks @andrewmlim this has been merged 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.
---

[GitHub] nifi pull request #1512: NIFI-3480 Fix incorrect Admin Guide documentation r...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/nifi/pull/1512


---
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-3480) Fix incorrect Admin Guide documentation regarding anonymous access

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15870070#comment-15870070
 ] 

ASF subversion and git services commented on NIFI-3480:
---

Commit 702a0dcf17d9a6e1372935ef0363fe59bd216a65 in nifi's branch 
refs/heads/master from [~andrewmlim]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=702a0dc ]

NIFI-3480 Fix incorrect Admin Guide documentation regarding anonymous access

This closes #1512


> Fix incorrect Admin Guide documentation regarding anonymous access
> --
>
> Key: NIFI-3480
> URL: https://issues.apache.org/jira/browse/NIFI-3480
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Documentation & Website
>Affects Versions: 1.1.1
>Reporter: Andy LoPresto
>Assignee: Andrew Lim
>Priority: Trivial
>  Labels: documentation, security
>
> The Admin Guide *Security Configuration* section states
> {quote}
> {{nifi.security.truststore}}
> Filename of the Truststore that will be used to authorize those connecting to 
> NiFi. If not set, all who attempt to connect will be provided access as the 
> *Anonymous* user.
> {quote}
> This is incorrect and misleading. The only way to configure a secured 
> instance with anonymous access is via LDAP or Kerberos and configuration of 
> the authorizer to explicitly allow anonymous access. Configuring a secured 
> instance with no truststore will simply refuse all incoming connections. 
> With {{nifi.security.needClientAuth}} set to {{true}} or empty (default):
> {code}
> 2017-02-14 12:03:05,546 WARN [Thread-1] 
> org.apache.nifi.web.server.JettyServer Failed to stop web server
> org.springframework.beans.factory.BeanCreationException: Error creating bean 
> with name 'flowService': FactoryBean threw exception on object creation; 
> nested exception is org.springframework.beans.factory.BeanCreationException: 
> Error creating bean with name 'flowController': FactoryBean threw exception 
> on object creation; nested exception is 
> org.apache.nifi.framework.security.util.SslContextCreationException: Need 
> client auth is set to 'true', but no truststore properties are configured.
>   at 
> org.springframework.beans.factory.support.FactoryBeanRegistrySupport.doGetObjectFromFactoryBean(FactoryBeanRegistrySupport.java:175)
>  ~[na:na]
>   at 
> org.springframework.beans.factory.support.FactoryBeanRegistrySupport.getObjectFromFactoryBean(FactoryBeanRegistrySupport.java:103)
>  ~[na:na]
>   at 
> org.springframework.beans.factory.support.AbstractBeanFactory.getObjectForBeanInstance(AbstractBeanFactory.java:1585)
>  ~[na:na]
>   at 
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:254)
>  ~[na:na]
>   at 
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:202)
>  ~[na:na]
>   at 
> org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:1060)
>  ~[na:na]
>   at 
> org.apache.nifi.web.contextlistener.ApplicationStartupContextListener.contextDestroyed(ApplicationStartupContextListener.java:103)
>  ~[na:na]
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.callContextDestroyed(ContextHandler.java:845)
>  ~[na:na]
>   at 
> org.eclipse.jetty.servlet.ServletContextHandler.callContextDestroyed(ServletContextHandler.java:546)
>  ~[na:na]
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.stopContext(ContextHandler.java:826)
>  ~[na:na]
>   at 
> org.eclipse.jetty.servlet.ServletContextHandler.stopContext(ServletContextHandler.java:356)
>  ~[na:na]
>   at 
> org.eclipse.jetty.webapp.WebAppContext.stopWebapp(WebAppContext.java:1410) 
> ~[na:na]
>   at 
> org.eclipse.jetty.webapp.WebAppContext.stopContext(WebAppContext.java:1374) 
> ~[na:na]
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doStop(ContextHandler.java:874)
>  ~[na:na]
>   at 
> org.eclipse.jetty.servlet.ServletContextHandler.doStop(ServletContextHandler.java:272)
>  ~[na:na]
>   at 
> org.eclipse.jetty.webapp.WebAppContext.doStop(WebAppContext.java:544) ~[na:na]
>   at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
>  ~[na:na]
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:143)
>  ~[na:na]
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:161)
>  ~[na:na]
>   at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStop(AbstractHandler.java:73)
>  ~[na:na]
>   at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
>  ~[na:na]
>   at 
> 

[GitHub] nifi issue #1512: NIFI-3480 Fix incorrect Admin Guide documentation regardin...

[scottyaslan]

Github user scottyaslan commented on the issue:

https://github.com/apache/nifi/pull/1512
  
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-3480) Fix incorrect Admin Guide documentation regarding anonymous access

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15870028#comment-15870028
 ] 

ASF GitHub Bot commented on NIFI-3480:
--

Github user scottyaslan commented on the issue:

https://github.com/apache/nifi/pull/1512
  
reviewing...


> Fix incorrect Admin Guide documentation regarding anonymous access
> --
>
> Key: NIFI-3480
> URL: https://issues.apache.org/jira/browse/NIFI-3480
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Documentation & Website
>Affects Versions: 1.1.1
>Reporter: Andy LoPresto
>Assignee: Andrew Lim
>Priority: Trivial
>  Labels: documentation, security
>
> The Admin Guide *Security Configuration* section states
> {quote}
> {{nifi.security.truststore}}
> Filename of the Truststore that will be used to authorize those connecting to 
> NiFi. If not set, all who attempt to connect will be provided access as the 
> *Anonymous* user.
> {quote}
> This is incorrect and misleading. The only way to configure a secured 
> instance with anonymous access is via LDAP or Kerberos and configuration of 
> the authorizer to explicitly allow anonymous access. Configuring a secured 
> instance with no truststore will simply refuse all incoming connections. 
> With {{nifi.security.needClientAuth}} set to {{true}} or empty (default):
> {code}
> 2017-02-14 12:03:05,546 WARN [Thread-1] 
> org.apache.nifi.web.server.JettyServer Failed to stop web server
> org.springframework.beans.factory.BeanCreationException: Error creating bean 
> with name 'flowService': FactoryBean threw exception on object creation; 
> nested exception is org.springframework.beans.factory.BeanCreationException: 
> Error creating bean with name 'flowController': FactoryBean threw exception 
> on object creation; nested exception is 
> org.apache.nifi.framework.security.util.SslContextCreationException: Need 
> client auth is set to 'true', but no truststore properties are configured.
>   at 
> org.springframework.beans.factory.support.FactoryBeanRegistrySupport.doGetObjectFromFactoryBean(FactoryBeanRegistrySupport.java:175)
>  ~[na:na]
>   at 
> org.springframework.beans.factory.support.FactoryBeanRegistrySupport.getObjectFromFactoryBean(FactoryBeanRegistrySupport.java:103)
>  ~[na:na]
>   at 
> org.springframework.beans.factory.support.AbstractBeanFactory.getObjectForBeanInstance(AbstractBeanFactory.java:1585)
>  ~[na:na]
>   at 
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:254)
>  ~[na:na]
>   at 
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:202)
>  ~[na:na]
>   at 
> org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:1060)
>  ~[na:na]
>   at 
> org.apache.nifi.web.contextlistener.ApplicationStartupContextListener.contextDestroyed(ApplicationStartupContextListener.java:103)
>  ~[na:na]
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.callContextDestroyed(ContextHandler.java:845)
>  ~[na:na]
>   at 
> org.eclipse.jetty.servlet.ServletContextHandler.callContextDestroyed(ServletContextHandler.java:546)
>  ~[na:na]
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.stopContext(ContextHandler.java:826)
>  ~[na:na]
>   at 
> org.eclipse.jetty.servlet.ServletContextHandler.stopContext(ServletContextHandler.java:356)
>  ~[na:na]
>   at 
> org.eclipse.jetty.webapp.WebAppContext.stopWebapp(WebAppContext.java:1410) 
> ~[na:na]
>   at 
> org.eclipse.jetty.webapp.WebAppContext.stopContext(WebAppContext.java:1374) 
> ~[na:na]
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doStop(ContextHandler.java:874)
>  ~[na:na]
>   at 
> org.eclipse.jetty.servlet.ServletContextHandler.doStop(ServletContextHandler.java:272)
>  ~[na:na]
>   at 
> org.eclipse.jetty.webapp.WebAppContext.doStop(WebAppContext.java:544) ~[na:na]
>   at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
>  ~[na:na]
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:143)
>  ~[na:na]
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:161)
>  ~[na:na]
>   at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStop(AbstractHandler.java:73)
>  ~[na:na]
>   at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
>  ~[na:na]
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:143)
>  ~[na:na]
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:161)
>  ~[na:na]
>   at 
> 

[jira] [Updated] (NIFI-3491) fake flow file causes exception when starting NiFi

[Majid Hajibaba (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-3491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Majid Hajibaba updated NIFI-3491:
-
Description: 
Some flow files are remained in queues but queues seems empty! However when we 
restart NiFi, exceptions like the following appears:

{code}

o.a.n.p.kafka.pubsub.PublishKafka_0_10 
PublishKafka_0_10[id=a7853f14-0159-1000-dff2-7211d462f914] 
PublishKafka_0_10[id=a7853f14-0159-1000-dff2-7211d462f914] failed to process 
due to java.lang.IllegalArgumentException: No enum constant 
org.wali.UpdateType.CONTENTMISSING; rolling back session: 
java.lang.IllegalArgumentException: No enum constant 
org.wali.UpdateType.CONTENTMISSING
2017-02-16 13:06:18,773 ERROR [Timer-Driven Process Thread-3] 
o.a.n.p.kafka.pubsub.PublishKafka_0_10 
java.lang.IllegalArgumentException: No enum constant 
org.wali.UpdateType.CONTENTMISSING
at java.lang.Enum.valueOf(Enum.java:238) ~[na:1.8.0_45]
at org.wali.UpdateType.valueOf(UpdateType.java:24) 
~[nifi-write-ahead-log-1.1.0.jar:1.1.0]
at 
org.apache.nifi.controller.repository.schema.RepositoryRecordUpdate.getFieldValue(RepositoryRecordUpdate.java:43)
 ~[nifi-framework-core-1.1.0.jar:1.1.0]
at 
org.apache.nifi.repository.schema.Record.getFieldValue(Record.java:27) 
~[nifi-schema-utils-1.1.0.jar:1.1.0]
at 
org.apache.nifi.repository.schema.SchemaRecordWriter.writeRecordFields(SchemaRecordWriter.java:41)
 ~[nifi-schema-utils-1.1.0.jar:1.1.0]
at 
org.apache.nifi.repository.schema.SchemaRecordWriter.writeRecord(SchemaRecordWriter.java:35)
 ~[nifi-schema-utils-1.1.0.jar:1.1.0]
at 
org.apache.nifi.controller.repository.SchemaRepositoryRecordSerde.serializeRecord(SchemaRepositoryRecordSerde.java:95)
 ~[nifi-framework-core-1.1.0.jar:1.1.0]
at 
org.apache.nifi.controller.repository.SchemaRepositoryRecordSerde.serializeEdit(SchemaRepositoryRecordSerde.java:67)
 ~[nifi-framework-core-1.1.0.jar:1.1.0]
at 
org.apache.nifi.controller.repository.SchemaRepositoryRecordSerde.serializeEdit(SchemaRepositoryRecordSerde.java:46)
 ~[nifi-framework-core-1.1.0.jar:1.1.0]
at 
org.wali.MinimalLockingWriteAheadLog$Partition.update(MinimalLockingWriteAheadLog.java:957)
 ~[nifi-write-ahead-log-1.1.0.jar:1.1.0]
at 
org.wali.MinimalLockingWriteAheadLog.update(MinimalLockingWriteAheadLog.java:238)
 ~[nifi-write-ahead-log-1.1.0.jar:1.1.0]
at 
org.apache.nifi.controller.repository.WriteAheadFlowFileRepository.updateRepository(WriteAheadFlowFileRepository.java:210)
 ~[nifi-framework-core-1.1.0.jar:1.1.0]
at 
org.apache.nifi.controller.repository.WriteAheadFlowFileRepository.updateRepository(WriteAheadFlowFileRepository.java:178)
 ~[nifi-framework-core-1.1.0.jar:1.1.0]
at 
org.apache.nifi.controller.repository.StandardProcessSession.rollback(StandardProcessSession.java:967)
 ~[nifi-framework-core-1.1.0.jar:1.1.0]
at 
org.apache.nifi.controller.repository.StandardProcessSession.rollback(StandardProcessSession.java:882)
 ~[nifi-framework-core-1.1.0.jar:1.1.0]
at 
org.apache.nifi.controller.repository.StandardProcessSession.rollback(StandardProcessSession.java:877)
 ~[nifi-framework-core-1.1.0.jar:1.1.0]
at 
org.apache.nifi.controller.repository.StandardProcessSession.handleContentNotFound(StandardProcessSession.java:2784)
 ~[nifi-framework-core-1.1.0.jar:1.1.0]
at 
org.apache.nifi.controller.repository.StandardProcessSession.read(StandardProcessSession.java:2103)
 ~[nifi-framework-core-1.1.0.jar:1.1.0]
at 
org.apache.nifi.controller.repository.StandardProcessSession.read(StandardProcessSession.java:2053)
 ~[nifi-framework-core-1.1.0.jar:1.1.0]
at 
org.apache.nifi.processors.kafka.pubsub.PublishKafka_0_10.onTrigger(PublishKafka_0_10.java:330)
 ~[nifi-kafka-0-10-processors-1.1.0.jar:1.1.0]
at 
org.apache.nifi.processor.AbstractProcessor.onTrigger(AbstractProcessor.java:27)
 ~[nifi-api-1.1.0.jar:1.1.0]
at 
org.apache.nifi.controller.StandardProcessorNode.onTrigger(StandardProcessorNode.java:1099)
 [nifi-framework-core-1.1.0.jar:1.1.0]
at 
org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:136)
 [nifi-framework-core-1.1.0.jar:1.1.0]
at 
org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:47)
 [nifi-framework-core-1.1.0.jar:1.1.0]
at 
org.apache.nifi.controller.scheduling.TimerDrivenSchedulingAgent$1.run(TimerDrivenSchedulingAgent.java:132)
 [nifi-framework-core-1.1.0.jar:1.1.0]
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
[na:1.8.0_45]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) 
[na:1.8.0_45]
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
 [na:1.8.0_45]
at 

[jira] [Created] (NIFI-3491) fake flow file causes exception when starting NiFi

[Majid Hajibaba (JIRA)]

Majid Hajibaba created NIFI-3491:


 Summary: fake flow file causes exception when starting NiFi
 Key: NIFI-3491
 URL: https://issues.apache.org/jira/browse/NIFI-3491
 Project: Apache NiFi
  Issue Type: Bug
  Components: Core Framework
Affects Versions: 1.1.0
Reporter: Majid Hajibaba


Some flow files are remained in queues but queues seems empty! However when we 
restart NiFi, exceptions like the following appears:

`
o.a.n.p.kafka.pubsub.PublishKafka_0_10 
PublishKafka_0_10[id=a7853f14-0159-1000-dff2-7211d462f914] 
PublishKafka_0_10[id=a7853f14-0159-1000-dff2-7211d462f914] failed to process 
due to java.lang.IllegalArgumentException: No enum constant 
org.wali.UpdateType.CONTENTMISSING; rolling back session: 
java.lang.IllegalArgumentException: No enum constant 
org.wali.UpdateType.CONTENTMISSING
2017-02-16 13:06:18,773 ERROR [Timer-Driven Process Thread-3] 
o.a.n.p.kafka.pubsub.PublishKafka_0_10 
java.lang.IllegalArgumentException: No enum constant 
org.wali.UpdateType.CONTENTMISSING
at java.lang.Enum.valueOf(Enum.java:238) ~[na:1.8.0_45]
at org.wali.UpdateType.valueOf(UpdateType.java:24) 
~[nifi-write-ahead-log-1.1.0.jar:1.1.0]
at 
org.apache.nifi.controller.repository.schema.RepositoryRecordUpdate.getFieldValue(RepositoryRecordUpdate.java:43)
 ~[nifi-framework-core-1.1.0.jar:1.1.0]
at 
org.apache.nifi.repository.schema.Record.getFieldValue(Record.java:27) 
~[nifi-schema-utils-1.1.0.jar:1.1.0]
at 
org.apache.nifi.repository.schema.SchemaRecordWriter.writeRecordFields(SchemaRecordWriter.java:41)
 ~[nifi-schema-utils-1.1.0.jar:1.1.0]
at 
org.apache.nifi.repository.schema.SchemaRecordWriter.writeRecord(SchemaRecordWriter.java:35)
 ~[nifi-schema-utils-1.1.0.jar:1.1.0]
at 
org.apache.nifi.controller.repository.SchemaRepositoryRecordSerde.serializeRecord(SchemaRepositoryRecordSerde.java:95)
 ~[nifi-framework-core-1.1.0.jar:1.1.0]
at 
org.apache.nifi.controller.repository.SchemaRepositoryRecordSerde.serializeEdit(SchemaRepositoryRecordSerde.java:67)
 ~[nifi-framework-core-1.1.0.jar:1.1.0]
at 
org.apache.nifi.controller.repository.SchemaRepositoryRecordSerde.serializeEdit(SchemaRepositoryRecordSerde.java:46)
 ~[nifi-framework-core-1.1.0.jar:1.1.0]
at 
org.wali.MinimalLockingWriteAheadLog$Partition.update(MinimalLockingWriteAheadLog.java:957)
 ~[nifi-write-ahead-log-1.1.0.jar:1.1.0]
at 
org.wali.MinimalLockingWriteAheadLog.update(MinimalLockingWriteAheadLog.java:238)
 ~[nifi-write-ahead-log-1.1.0.jar:1.1.0]
at 
org.apache.nifi.controller.repository.WriteAheadFlowFileRepository.updateRepository(WriteAheadFlowFileRepository.java:210)
 ~[nifi-framework-core-1.1.0.jar:1.1.0]
at 
org.apache.nifi.controller.repository.WriteAheadFlowFileRepository.updateRepository(WriteAheadFlowFileRepository.java:178)
 ~[nifi-framework-core-1.1.0.jar:1.1.0]
at 
org.apache.nifi.controller.repository.StandardProcessSession.rollback(StandardProcessSession.java:967)
 ~[nifi-framework-core-1.1.0.jar:1.1.0]
at 
org.apache.nifi.controller.repository.StandardProcessSession.rollback(StandardProcessSession.java:882)
 ~[nifi-framework-core-1.1.0.jar:1.1.0]
at 
org.apache.nifi.controller.repository.StandardProcessSession.rollback(StandardProcessSession.java:877)
 ~[nifi-framework-core-1.1.0.jar:1.1.0]
at 
org.apache.nifi.controller.repository.StandardProcessSession.handleContentNotFound(StandardProcessSession.java:2784)
 ~[nifi-framework-core-1.1.0.jar:1.1.0]
at 
org.apache.nifi.controller.repository.StandardProcessSession.read(StandardProcessSession.java:2103)
 ~[nifi-framework-core-1.1.0.jar:1.1.0]
at 
org.apache.nifi.controller.repository.StandardProcessSession.read(StandardProcessSession.java:2053)
 ~[nifi-framework-core-1.1.0.jar:1.1.0]
at 
org.apache.nifi.processors.kafka.pubsub.PublishKafka_0_10.onTrigger(PublishKafka_0_10.java:330)
 ~[nifi-kafka-0-10-processors-1.1.0.jar:1.1.0]
at 
org.apache.nifi.processor.AbstractProcessor.onTrigger(AbstractProcessor.java:27)
 ~[nifi-api-1.1.0.jar:1.1.0]
at 
org.apache.nifi.controller.StandardProcessorNode.onTrigger(StandardProcessorNode.java:1099)
 [nifi-framework-core-1.1.0.jar:1.1.0]
at 
org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:136)
 [nifi-framework-core-1.1.0.jar:1.1.0]
at 
org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:47)
 [nifi-framework-core-1.1.0.jar:1.1.0]
at 
org.apache.nifi.controller.scheduling.TimerDrivenSchedulingAgent$1.run(TimerDrivenSchedulingAgent.java:132)
 [nifi-framework-core-1.1.0.jar:1.1.0]
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
[na:1.8.0_45]
at 

[jira] [Commented] (NIFI-2613) Support extracting content from Microsoft Excel (.xlxs) documents

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15869940#comment-15869940
 ] 

ASF GitHub Bot commented on NIFI-2613:
--

Github user jdye64 commented on the issue:

https://github.com/apache/nifi/pull/929
  
@jvwing thank you for pointing this out. Let me look it over right now and 
I'll make another commit shortly. I had this in another project and I think 
during the copy/paste I have made an error.


> Support extracting content from Microsoft Excel (.xlxs) documents
> -
>
> Key: NIFI-2613
> URL: https://issues.apache.org/jira/browse/NIFI-2613
> Project: Apache NiFi
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Jeremy Dyer
>Assignee: Jeremy Dyer
>
> Microsoft Excel is a wildly popular application that businesses rely heavily 
> on to store, visualize, and calculate data. Any single company most likely 
> has thousands of Excel documents containing data that could be very valuable 
> if ingested via NiFi and combined with other datasources. Apache POI is a 
> popular 100% Java library for parsing several Microsoft document formats 
> including Excel. Apache POI is extremely flexible and can do several things. 
> This issue would focus solely on using Apache POI to parse an incoming .xlxs 
> document and convert it to CSV. The processor should be capable of limiting 
> which excel sheets. CSV seems like the natural choice for outputting each row 
> since this feature is already available in Excel and feels very natural to 
> most Excel sheet designs.
> This capability should most likely introduce a new "poi" module as I envision 
> many more capabilities around parsing Microsoft documents could come from 
> this base effort.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] nifi issue #929: NIFI-2613 - Apache POI processor to convert Excel documents...

[jdye64]

Github user jdye64 commented on the issue:

https://github.com/apache/nifi/pull/929
  
@jvwing thank you for pointing this out. Let me look it over right now and 
I'll make another commit shortly. I had this in another project and I think 
during the copy/paste I have made an error.


---
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-2890) Provenance Repository corruption

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15869863#comment-15869863
 ] 

ASF GitHub Bot commented on NIFI-2890:
--

Github user jskora closed the pull request at:

https://github.com/apache/nifi/pull/1484


> Provenance Repository corruption
> 
>
> Key: NIFI-2890
> URL: https://issues.apache.org/jira/browse/NIFI-2890
> Project: Apache NiFi
>  Issue Type: Bug
>Affects Versions: 1.0.0, 0.7.0
>Reporter: Brandon DeVries
>Assignee: Joe Skora
> Fix For: 0.8.0, 1.2.0
>
>
> It looks as thought there was a ticket to address this\[1\], but it appears 
> to not have completely addressed the issue. On an 0.6.1 instance (that 
> crashed hard), I'm getting a stack trace on startup indicating a corrupt prov 
> repo. The relevant part of the stack trace (unfortunately typed by hand, so 
> forgive the inevitable typos) is:
> {quote}
> ...
> Caused By java.lang.IllegalArgumentException: No enum constant 
> org.apahe.nifi.provenance.ProvenenceEventType.
> at java.lang/.Enum.valueOf...
> at 
> org.apache.nifi.provenance.ProvenanaceEventType.valueOf(ProvenanaceEventType.java:19)
> at
> org.apache.nifi.provenance.StandardRecordReader.nextRecord(StandardRecordReader.java:284)
> at 
> org.apache.nifi.provenance.PersistentProvenanceRepository.mergeJournals(PersistentProvenanceRepository.java:1678)
>  \[2\]
> ...
> {quote}
> In 0.x HEAD, this appears to have moved a bit\[3\]. Same is true for 
> 1.x\[4\]. In both 0.x\[5\] and 1.x\[6\], code was added to check for "bad" 
> records coming from the reader, and skip them. However, this appears to only 
> address the issue if the corrupt / bad record is the *first* record coming 
> out of a reader. If it is a subsequent record, the corruption remains.
> \[1\] https://issues.apache.org/jira/browse/NIFI-803
> \[2\] 
> https://github.com/apache/nifi/blob/rel/nifi-0.6.1/nifi-nar-bundles/nifi-provenance-repository-bundle/nifi-persistent-provenance-repository/src/main/java/org/apache/nifi/provenance/PersistentProvenanceRepository.java#L1678
> \[3\] 
> https://github.com/apache/nifi/blob/0.x/nifi-nar-bundles/nifi-provenance-repository-bundle/nifi-persistent-provenance-repository/src/main/java/org/apache/nifi/provenance/PersistentProvenanceRepository.java#L1711
> \[4\] 
> https://github.com/apache/nifi/blob/rel/nifi-0.6.1/nifi-nar-bundles/nifi-provenance-repository-bundle/nifi-persistent-provenance-repository/src/main/java/org/apache/nifi/provenance/PersistentProvenanceRepository.java#L1678
> \[5\] 
> https://github.com/apache/nifi/blob/0.x/nifi-nar-bundles/nifi-provenance-repository-bundle/nifi-persistent-provenance-repository/src/main/java/org/apache/nifi/provenance/PersistentProvenanceRepository.java#L1564-L1578
> \[6\] 
> https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-provenance-repository-bundle/nifi-persistent-provenance-repository/src/main/java/org/apache/nifi/provenance/PersistentProvenanceRepository.java#L1658-L1672



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] nifi pull request #1484: NIFI-2890 Provenance Repository Corruption (0.x)

[jskora]

Github user jskora closed the pull request at:

https://github.com/apache/nifi/pull/1484


---
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-2890) Provenance Repository corruption

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15869862#comment-15869862
 ] 

ASF GitHub Bot commented on NIFI-2890:
--

Github user jskora commented on the issue:

https://github.com/apache/nifi/pull/1484
  
Committed on 
[7d23bd7](https://git-wip-us.apache.org/repos/asf?p=nifi.git;a=commit;h=7d23bd7ac6af228a3e723d18253063231c919cf9).


> Provenance Repository corruption
> 
>
> Key: NIFI-2890
> URL: https://issues.apache.org/jira/browse/NIFI-2890
> Project: Apache NiFi
>  Issue Type: Bug
>Affects Versions: 1.0.0, 0.7.0
>Reporter: Brandon DeVries
>Assignee: Joe Skora
> Fix For: 0.8.0, 1.2.0
>
>
> It looks as thought there was a ticket to address this\[1\], but it appears 
> to not have completely addressed the issue. On an 0.6.1 instance (that 
> crashed hard), I'm getting a stack trace on startup indicating a corrupt prov 
> repo. The relevant part of the stack trace (unfortunately typed by hand, so 
> forgive the inevitable typos) is:
> {quote}
> ...
> Caused By java.lang.IllegalArgumentException: No enum constant 
> org.apahe.nifi.provenance.ProvenenceEventType.
> at java.lang/.Enum.valueOf...
> at 
> org.apache.nifi.provenance.ProvenanaceEventType.valueOf(ProvenanaceEventType.java:19)
> at
> org.apache.nifi.provenance.StandardRecordReader.nextRecord(StandardRecordReader.java:284)
> at 
> org.apache.nifi.provenance.PersistentProvenanceRepository.mergeJournals(PersistentProvenanceRepository.java:1678)
>  \[2\]
> ...
> {quote}
> In 0.x HEAD, this appears to have moved a bit\[3\]. Same is true for 
> 1.x\[4\]. In both 0.x\[5\] and 1.x\[6\], code was added to check for "bad" 
> records coming from the reader, and skip them. However, this appears to only 
> address the issue if the corrupt / bad record is the *first* record coming 
> out of a reader. If it is a subsequent record, the corruption remains.
> \[1\] https://issues.apache.org/jira/browse/NIFI-803
> \[2\] 
> https://github.com/apache/nifi/blob/rel/nifi-0.6.1/nifi-nar-bundles/nifi-provenance-repository-bundle/nifi-persistent-provenance-repository/src/main/java/org/apache/nifi/provenance/PersistentProvenanceRepository.java#L1678
> \[3\] 
> https://github.com/apache/nifi/blob/0.x/nifi-nar-bundles/nifi-provenance-repository-bundle/nifi-persistent-provenance-repository/src/main/java/org/apache/nifi/provenance/PersistentProvenanceRepository.java#L1711
> \[4\] 
> https://github.com/apache/nifi/blob/rel/nifi-0.6.1/nifi-nar-bundles/nifi-provenance-repository-bundle/nifi-persistent-provenance-repository/src/main/java/org/apache/nifi/provenance/PersistentProvenanceRepository.java#L1678
> \[5\] 
> https://github.com/apache/nifi/blob/0.x/nifi-nar-bundles/nifi-provenance-repository-bundle/nifi-persistent-provenance-repository/src/main/java/org/apache/nifi/provenance/PersistentProvenanceRepository.java#L1564-L1578
> \[6\] 
> https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-provenance-repository-bundle/nifi-persistent-provenance-repository/src/main/java/org/apache/nifi/provenance/PersistentProvenanceRepository.java#L1658-L1672



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] nifi issue #1484: NIFI-2890 Provenance Repository Corruption (0.x)

[jskora]

Github user jskora commented on the issue:

https://github.com/apache/nifi/pull/1484
  
Committed on 
[7d23bd7](https://git-wip-us.apache.org/repos/asf?p=nifi.git;a=commit;h=7d23bd7ac6af228a3e723d18253063231c919cf9).


---
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 #43: MINIFI-183 Implemented ListenHTTP

[achristianson]

Github user achristianson commented on the issue:

https://github.com/apache/nifi-minifi-cpp/pull/43
  
@apiri @phrocker Addressed the comments, updated the code, and rebased. The 
biggest thing is cleanly setting up an ExternalProject system, but I think 
that's best addressed under the ticket @phrocker created.


---
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 pull request #43: MINIFI-183 Implemented ListenHTTP

[achristianson]

Github user achristianson commented on a diff in the pull request:

https://github.com/apache/nifi-minifi-cpp/pull/43#discussion_r101502981
  
--- Diff: libminifi/CMakeLists.txt ---
@@ -48,6 +49,19 @@ file(GLOB SPD_SOURCES "../include/spdlog/*")
 add_library(spdlog STATIC ${SPD_SOURCES})
 add_library(minifi STATIC ${SOURCES})
 
+# Include Boost System
+find_package(Boost COMPONENTS system REQUIRED)
--- End diff --

@phrocker Yes, that's for civet.


---
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 pull request #43: MINIFI-183 Implemented ListenHTTP

[achristianson]

Github user achristianson commented on a diff in the pull request:

https://github.com/apache/nifi-minifi-cpp/pull/43#discussion_r101504064
  
--- Diff: libminifi/include/ProcessSessionFactory.h ---
@@ -0,0 +1,52 @@
+/**
+ * @file ProcessSessionFactory.h
+ * ProcessSessionFactory class declaration
+ *
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+#ifndef __PROCESS_SESSION_FACTORY_H__
+#define __PROCESS_SESSION_FACTORY_H__
+
+#include 
+
+#include "ProcessContext.h"
+#include "ProcessSession.h"
+
+//! ProcessSessionFactory Class
+class ProcessSessionFactory
+{
+public:
+   //! Constructor
+   /*!
+* Create a new process session factory
+*/
+   ProcessSessionFactory(ProcessContext *processContext) : 
_processContext(processContext) {}
+
+   //! Create the session
+   std::unique_ptr createSession();
--- End diff --

@phrocker No problem. It makes it a lot easier to avoid memory management 
bugs.


---
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 pull request #43: MINIFI-183 Implemented ListenHTTP

[achristianson]

Github user achristianson commented on a diff in the pull request:

https://github.com/apache/nifi-minifi-cpp/pull/43#discussion_r101507876
  
--- Diff: libminifi/src/ThreadedSchedulingAgent.cpp ---
@@ -64,11 +68,18 @@ void ThreadedSchedulingAgent::schedule(Processor 
*processor)
return;
}
 
+   auto processContext = std::make_shared(processor);
--- End diff --

@phrocker Mainly, creating a shared ProcessContext and SessionFactory which 
will be used in this thread as well as the threads created in the loop below. I 
wanted these objects to be cleaned up once they go out of scope in all threads. 
The raw pointers are only used to integrate with the existing Processor pointer 
that is passed-in, as well as passing raw pointers to the constructors of the 
new shared objects. I wanted to minimize function/constructor changes that 
might have impacts elsewhere in the code base. If we want to move more to 
having managed pointers across the code base, then some of this can be cleaned 
up.


---
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 pull request #43: MINIFI-183 Implemented ListenHTTP

[achristianson]

Github user achristianson commented on a diff in the pull request:

https://github.com/apache/nifi-minifi-cpp/pull/43#discussion_r101504515
  
--- Diff: libminifi/include/ProcessSessionFactory.h ---
@@ -0,0 +1,52 @@
+/**
+ * @file ProcessSessionFactory.h
+ * ProcessSessionFactory class declaration
+ *
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+#ifndef __PROCESS_SESSION_FACTORY_H__
+#define __PROCESS_SESSION_FACTORY_H__
+
+#include 
+
+#include "ProcessContext.h"
+#include "ProcessSession.h"
+
+//! ProcessSessionFactory Class
+class ProcessSessionFactory
+{
+public:
+   //! Constructor
+   /*!
+* Create a new process session factory
+*/
+   ProcessSessionFactory(ProcessContext *processContext) : 
_processContext(processContext) {}
--- End diff --

@phrocker Done.


---
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-3414) Implement an EnforceOrder processor

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15869812#comment-15869812
 ] 

ASF GitHub Bot commented on NIFI-3414:
--

Github user ijokarumawak commented on the issue:

https://github.com/apache/nifi/pull/1496
  
Hey @pvillard31 thanks for trying out this PR. I've update it to use both 
`.name()` and `.displayName`. Please let me know if you find anything 
suspicious during your test.


> Implement an EnforceOrder processor
> ---
>
> Key: NIFI-3414
> URL: https://issues.apache.org/jira/browse/NIFI-3414
> Project: Apache NiFi
>  Issue Type: New Feature
>Reporter: Matt Burgess
>Assignee: Koji Kawamura
>
> For some flows, it is imperative that the flow files are processed in a 
> certain order.  The PriorityAttributePrioritizer can be used on a connection 
> to ensure that flow files going through that connection are in priority 
> order, but depending on error-handling, branching, and other flow designs, it 
> is possible for flow files to get out-of-order.
> I propose an EnforceOrder processor, which would be single-threaded and have 
> (at a minimum) the following properties:
> 1) Order Attribute: This would be the name of a flow file attribute from 
> which the current value will be retrieved.
> 2) Initial Value: This property specifies an initial value for the order. The 
> processor is stateful, however, so this property is only used when there is 
> no entry in the state map for current value.
> The processor would store the Initial Value into the state map (if no state 
> map entry exists), then for each incoming flow file, it checks the value in 
> the Order Attribute against the current value.  If the attribute value 
> matches the current value, the flow file is transferred to the "success" 
> relationship, and the current value is incremented in the state map. If the 
> attribute value does not match the current value, the session will be rolled 
> back.
> Using this processor, along with a PriorityAttributePrioritizer on the 
> incoming connection, will allow for out-of-order flow files to have a sort of 
> "barrier", thereby guaranteeing that flow files transferred to the "success" 
> relationship are in the specified order.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] nifi issue #1496: NIFI-3414: Added EnforceOrder processor

[ijokarumawak]

Github user ijokarumawak commented on the issue:

https://github.com/apache/nifi/pull/1496
  
Hey @pvillard31 thanks for trying out this PR. I've update it to use both 
`.name()` and `.displayName`. Please let me know if you find anything 
suspicious during your test.


---
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-3213) ListFile always skips files with the latest timestamp in an iteration even if the files have existed a while ago

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15869791#comment-15869791
 ] 

ASF GitHub Bot commented on NIFI-3213:
--

Github user ijokarumawak commented on the issue:

https://github.com/apache/nifi/pull/1335
  
@trixpan Thanks for reviewing and catching the unit test failure. Yes, I'd 
like to look at it closer. I will update the PR accordingly.


> ListFile always skips files with the latest timestamp in an iteration even if 
> the files have existed a while ago
> 
>
> Key: NIFI-3213
> URL: https://issues.apache.org/jira/browse/NIFI-3213
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: 1.0.0, 0.5.0, 0.6.0, 0.5.1, 0.7.0, 0.6.1, 1.1.0, 0.7.1
>Reporter: Koji Kawamura
>Assignee: Koji Kawamura
>
> NIFI-1484 add few lines of code to avoid files to be emitted if those have 
> the latest timestamp within an iteration of listing, because it may still be 
> written at the same time.
> While it doesn't affect much if ListFiles processor is scheduled with a short 
> period of time, such as few ms, but it does affect negatively if an user 
> scheduled it with longer run schedule such as "1 day" or with cron scheduler. 
> For example, user would expect to process list of files per daily basis. Even 
> if a file is saved few hours ago, the processor will skip this, because the 
> file has the latest timestamp within the iteration.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)