[jira] [Commented] (NIFI-3701) Documentation improvements for 1.x

[Mark Bean (JIRA)]

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

Mark Bean commented on NIFI-3701:
-

Here is a first pass at items that need attention in the documentation. Some 
are extremely minor, others more significant. Most comments apply to the Admin 
Guide, and a couple to the User Guide.

ADMIN GUIDE
Update table showing mapping of legacy roles to policies to more closely align 
with policy nomenclature in the UI:
Policy "view the dataflow" and "modify the dataflow" should read "access the 
controller/view" and "access the controller/modify", or "view the controller" 
and "modify the controller". The point being replace "dataflow" with 
"controller".
Policy "view policies" should read "view all policies". Same for 'modify'.
Policy "send proxy user requests" should read "proxy user requests"
Are any of the following policies applied during the migration from legacy 
roles? If so, they should be added to the table.
  view system diagnostics
  access counters

authorizations.xml in Cluster
There is a note indicating "In a cluster, all nodes must have the same 
authorization.xml...". This is also true of users.xml.
Also, this same note mentions an empty authorizations.xml will inherit from the 
cluster. This is true only if neither 'Initial Admin Identity' nor 'Legacy 
Authorized Users File' property is set. These will generate non-empty 
authorizations.xml and users.xml prior thus preventing inheritance from the 
Cluster.

Component Level Access Policies
Table indicates policy "retrieve data via site-to-site"; should be "receive 
data via site-to-site"
  
Templates
Mention the new use of templates. Specifically, the nifi.templates.directory is 
for backward compatibility only; templates are now stored in the flow.xml.gz. 
Also, mention that the template directory can be used to [bulk] import 
templates into the flow.xml.gz automatically on NiFi  startup.

List/Empty Queue in Cluster
A user requires 'view the data' policy for List Queue and 'modify the data' for 
Delete Queue. This is documented. What is not is that all Nodes of a Cluster 
must also be part of those policies.


USER GUIDE
Configure Site-to-Site does not clearly reference modifying the Policy of an 
Input Port to allow access. It implies the 0.x method of adding accesses 
through the "configure" option of the Input Port. It also mentions Access 
Control, and states that the first time a client establishes a connection, the 
client will be forbidden and a request for an account for that client will 
automatically be generated. And, it mentions the client is required to have 
NiFi Role. There are numerous items here which are now obsolete.

Backpressure sections should mention the default limits imposed on every new 
connection.


> Documentation improvements for 1.x
> --
>
> Key: NIFI-3701
> URL: https://issues.apache.org/jira/browse/NIFI-3701
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Documentation & Website
>Reporter: Mark Bean
>Priority: Minor
>
> This ticket is intended to track various documentation enhancement requests 
> particularly as they apply to 1.x as compared to 0.x. Additional details will 
> be added as separate updates.



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

[jira] [Updated] (NIFI-3706) FileAuthorizer - Grants permissions to non-existent policy

[Matt Gilman (JIRA)]

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

Matt Gilman updated NIFI-3706:
--
Fix Version/s: 1.2.0
   Status: Patch Available  (was: Open)

> FileAuthorizer - Grants permissions to non-existent policy
> --
>
> Key: NIFI-3706
> URL: https://issues.apache.org/jira/browse/NIFI-3706
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Matt Gilman
>Priority: Trivial
> Fix For: 1.2.0
>
>
> When considering a legacy authorized users file, the FileAuthorizer grants 
> permission to WRITE site-to-site. These policy does not exist and is 
> consequently never evaluated. We should be able to remove it.



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

[jira] [Commented] (NIFI-3706) FileAuthorizer - Grants permissions to non-existent policy

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-3706:
--

GitHub user mcgilman opened a pull request:

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

NIFI-3706: Removing non-existent resource when converting a legacy 
authorized users file

- Removing non-existent resource when converting a legacy authorized users 
file.

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

$ git pull https://github.com/mcgilman/nifi NIFI-3706

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

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


commit 38f6f619ded6b833d88c52d0215817450e6901c1
Author: Matt Gilman 
Date:   2017-04-13T20:14:45Z

NIFI-3706:
- Removing non-existent resource when converting a legacy authorized users 
file.




> FileAuthorizer - Grants permissions to non-existent policy
> --
>
> Key: NIFI-3706
> URL: https://issues.apache.org/jira/browse/NIFI-3706
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Matt Gilman
>Priority: Trivial
> Fix For: 1.2.0
>
>
> When considering a legacy authorized users file, the FileAuthorizer grants 
> permission to WRITE site-to-site. These policy does not exist and is 
> consequently never evaluated. We should be able to remove it.



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

[GitHub] nifi pull request #1673: NIFI-3706: Removing non-existent resource when conv...

[mcgilman]

GitHub user mcgilman opened a pull request:

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

NIFI-3706: Removing non-existent resource when converting a legacy 
authorized users file

- Removing non-existent resource when converting a legacy authorized users 
file.

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

$ git pull https://github.com/mcgilman/nifi NIFI-3706

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

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


commit 38f6f619ded6b833d88c52d0215817450e6901c1
Author: Matt Gilman 
Date:   2017-04-13T20:14:45Z

NIFI-3706:
- Removing non-existent resource when converting a legacy authorized users 
file.




---
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-3707) UI - sort attributes on List Queue display

[Michael Moser (JIRA)]

Michael Moser created NIFI-3707:
---

 Summary: UI - sort attributes on List Queue display
 Key: NIFI-3707
 URL: https://issues.apache.org/jira/browse/NIFI-3707
 Project: Apache NiFi
  Issue Type: Improvement
  Components: Core UI
Affects Versions: 1.1.1
Reporter: Michael Moser
Priority: Minor


When I complete a Data Provenance query, and view the attributes of a flowfile, 
they are alphabetically sorted by attribute name.  However, when I do a List 
Queue query on a queue and view the attributes of a flowfile, they do not 
appear to be sorted.  It would be really nice if this display sorted attributes 
alphabetically by name, too.



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

[jira] [Updated] (NIFI-3706) FileAuthorizer - Grants permissions to non-existent policy

[Matt Gilman (JIRA)]

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

Matt Gilman updated NIFI-3706:
--
Description: When considering a legacy authorized users file, the 
FileAuthorizer grants permission to WRITE site-to-site. These policy does not 
exist and is consequently never evaluated. We should be able to remove it.  
(was: When considering the Initial Admin, the FileAuthorizer grants permission 
to WRITE site-to-site. These policy does not exist and is consequently never 
evaluated. We should be able to remove it.)

> FileAuthorizer - Grants permissions to non-existent policy
> --
>
> Key: NIFI-3706
> URL: https://issues.apache.org/jira/browse/NIFI-3706
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Matt Gilman
>Priority: Trivial
>
> When considering a legacy authorized users file, the FileAuthorizer grants 
> permission to WRITE site-to-site. These policy does not exist and is 
> consequently never evaluated. We should be able to remove it.



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

[jira] [Updated] (NIFI-3705) Web Api - Use supplied group details when verifying connection creation

[Matt Gilman (JIRA)]

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

Matt Gilman updated NIFI-3705:
--
Fix Version/s: 1.2.0
   Status: Patch Available  (was: Open)

> Web Api - Use supplied group details when verifying connection creation 
> 
>
> Key: NIFI-3705
> URL: https://issues.apache.org/jira/browse/NIFI-3705
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Reporter: Matt Gilman
>Assignee: Matt Gilman
> Fix For: 1.2.0
>
>
> When a connection is created, the request is verified. This verification 
> should use the supplied group details to be consistent with the actual 
> creation. Currently it simply searches from the root group.



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

[jira] [Commented] (NIFI-3705) Web Api - Use supplied group details when verifying connection creation

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-3705:
--

GitHub user mcgilman opened a pull request:

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

NIFI-3705: Using consistent logic when verifying connection creation

NIFI-3705:
- Using consistent logic when verifying connection creation. Removed some 
unnecessary checks as verification has been changed to run in cluster and 
standalone mode.

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

$ git pull https://github.com/mcgilman/nifi NIFI-3705

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

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


commit d882b6837f359b0fb4bdfd5d2f7608a8ab78b0d6
Author: Matt Gilman 
Date:   2017-04-13T19:58:42Z

NIFI-3705:
- Using consistent logic when verifying connection creation. Removed some 
unecessary checks as verification has been changed to run in cluster and 
standalone mode.




> Web Api - Use supplied group details when verifying connection creation 
> 
>
> Key: NIFI-3705
> URL: https://issues.apache.org/jira/browse/NIFI-3705
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Reporter: Matt Gilman
>Assignee: Matt Gilman
>
> When a connection is created, the request is verified. This verification 
> should use the supplied group details to be consistent with the actual 
> creation. Currently it simply searches from the root group.



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

[GitHub] nifi pull request #1672: NIFI-3705: Using consistent logic when verifying co...

[mcgilman]

GitHub user mcgilman opened a pull request:

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

NIFI-3705: Using consistent logic when verifying connection creation

NIFI-3705:
- Using consistent logic when verifying connection creation. Removed some 
unnecessary checks as verification has been changed to run in cluster and 
standalone mode.

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

$ git pull https://github.com/mcgilman/nifi NIFI-3705

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

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


commit d882b6837f359b0fb4bdfd5d2f7608a8ab78b0d6
Author: Matt Gilman 
Date:   2017-04-13T19:58:42Z

NIFI-3705:
- Using consistent logic when verifying connection creation. Removed some 
unecessary checks as verification has been changed to run in cluster and 
standalone mode.




---
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-3686) EOFException on swap in causes tight loop in polling for flowfiles

[Michael Moser (JIRA)]

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

Michael Moser commented on NIFI-3686:
-

I can change this ticket from Bug to Improvement for changing the schema so 
that each Record contains one FlowFile, and handling partial recovery.  And I 
will lower its priority because it's in the "we don't think this could happen 
and we accept the risk that we are wrong" category.

> EOFException on swap in causes tight loop in polling for flowfiles
> --
>
> Key: NIFI-3686
> URL: https://issues.apache.org/jira/browse/NIFI-3686
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.1.1
>Reporter: Michael Moser
>
> If flowfile_repository partition fills 100% while swapping files out to a new 
> swap file, then this swap file becomes corrupt (partially written).  When 
> NiFi tries to swap this file in, EOFException happens and we get following 
> ERROR, which is nice.
> 2017-04-10 18:02:58,855 ERROR [Timer-Driven Process Thread-3] 
> o.a.n.controller.StandardFlowFileQueue Failed to swap in FlowFiles from Swap 
> File 
> /local/mwmoser/nifi-1.2.0-SNAPSHOT/./flowfile_repository/swap/1491574631605-2840b630-57fc-4f49-615b-0b37d77bec66-5dbc0ad0-921c-483e-a05d-5c65d014fa48.swap;
>  Swap File appears to be corrupt!
> However, once all other dataflow stops, the queue now shows 1 flowfiles 
> in it.  The processor reading from this queue constantly has its onTrigger() 
> called, and session.get() polls the queue and gets 0 files returned.  This 
> happens in a tight loop, with no other errors.
> To a user it appears that the processor is doing lots of work but just not 
> processing those 1 files.  The error message above only appears once in 
> the nifi-app.log, so you don't see anything wrong if you tail the log. 
>  When you restart NiFi, the error message above appears again, but the user 
> experience of 1 files not processing remains.
> The new SchemaSwapDeserializer does not (and perhaps cannot) implement the 
> IncompleteSwapFileException that the old SimpleSwapDeserializer does.  So, 
> reading a swap file is currently all-or-nothing.



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

[jira] [Created] (NIFI-3706) FileAuthorizer - Grants permissions to non-existent policy

[Matt Gilman (JIRA)]

Matt Gilman created NIFI-3706:
-

 Summary: FileAuthorizer - Grants permissions to non-existent policy
 Key: NIFI-3706
 URL: https://issues.apache.org/jira/browse/NIFI-3706
 Project: Apache NiFi
  Issue Type: Bug
  Components: Extensions
Reporter: Matt Gilman
Priority: Trivial


When considering the Initial Admin, the FileAuthorizer grants permission to 
WRITE site-to-site. These policy does not exist and is consequently never 
evaluated. We should be able to remove it.



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

[jira] [Assigned] (NIFI-3678) NiFi may fail to startup if shutdown while FlowFile Repository partition is full

[Michael Moser (JIRA)]

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

Michael Moser reassigned NIFI-3678:
---

Assignee: Michael Moser  (was: Mark Payne)

> NiFi may fail to startup if shutdown while FlowFile Repository partition is 
> full
> 
>
> Key: NIFI-3678
> URL: https://issues.apache.org/jira/browse/NIFI-3678
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Reporter: Mark Payne
>Assignee: Michael Moser
> Fix For: 1.2.0
>
>
> A user from the users list posted that they are seeing the following stack 
> trace when trying to startup NiFi:
> {code}
> 2017-02-03 16:04:48,588 ERROR [main] o.a.nifi.controller.StandardFlowService 
> Failed to load flow from cluster due to: 
> org.apache.nifi.cluster.ConnectionException: Failed to connect node to 
> cluster due to: java.io.IOExcept 
> ion: Unable to read Record Schema from stream 
> org.apache.nifi.cluster.ConnectionException: Failed to connect node to 
> cluster due to: java.io.IOException: Unable to read Record Schema from stream 
> at 
> org.apache.nifi.controller.StandardFlowService.loadFromConnectionResponse(StandardFlowService.java:901)
>  ~[nifi-framework-core-1.1.0.jar:1.1.0] 
> at 
> org.apache.nifi.controller.StandardFlowService.load(StandardFlowService.java:493)
>  ~[nifi-framework-core-1.1.0.jar:1.1.0] 
> at org.apache.nifi.web.server.JettyServer.start(JettyServer.java:770) 
> [nifi-jetty-1.1.0.jar:1.1.0] 
> at org.apache.nifi.NiFi.(NiFi.java:156) 
> [nifi-runtime-1.1.0.jar:1.1.0] 
> at org.apache.nifi.NiFi.main(NiFi.java:262) 
> [nifi-runtime-1.1.0.jar:1.1.0] 
> Caused by: java.io.IOException: Unable to read Record Schema from stream 
> at 
> org.apache.nifi.repository.schema.RecordSchema.readFrom(RecordSchema.java:117)
>  ~[nifi-schema-utils-1.1.0.jar:1.1.0] 
> at 
> org.apache.nifi.controller.repository.SchemaRepositoryRecordSerde.readHeader(SchemaRepositoryRecordSerde.java:100)
>  ~[nifi-framework-core-1.1.0.jar:1.1.0] 
> at 
> org.wali.MinimalLockingWriteAheadLog$Partition.getRecoveryStream(MinimalLockingWriteAheadLog.java:1005)
>  ~[nifi-write-ahead-log-1.1.0.jar:1.1.0] 
> at 
> org.wali.MinimalLockingWriteAheadLog$Partition.getNextRecoverableTransactionId(MinimalLockingWriteAheadLog.java:1016)
>  ~[nifi-write-ahead-log-1.1.0.jar:1.1.0] 
> at 
> org.wali.MinimalLockingWriteAheadLog.recoverFromEdits(MinimalLockingWriteAheadLog.java:430)
>  ~[nifi-write-ahead-log-1.1.0.jar:1.1.0] 
> at 
> org.wali.MinimalLockingWriteAheadLog.recoverRecords(MinimalLockingWriteAheadLog.java:301)
>  ~[nifi-write-ahead-log-1.1.0.jar:1.1.0] 
> at 
> org.apache.nifi.controller.repository.WriteAheadFlowFileRepository.loadFlowFiles(WriteAheadFlowFileRepository.java:346)
>  ~[nifi-framework-core-1.1.0.jar:1.1.0] 
> at 
> org.apache.nifi.controller.FlowController.initializeFlow(FlowController.java:700)
>  ~[nifi-framework-core-1.1.0.jar:1.1.0] 
> at 
> org.apache.nifi.controller.StandardFlowService.loadFromBytes(StandardFlowService.java:701)
>  ~[nifi-framework-core-1.1.0.jar:1.1.0] 
> at 
> org.apache.nifi.controller.StandardFlowService.loadFromConnectionResponse(StandardFlowService.java:872)
>  ~[nifi-framework-core-1.1.0.jar:1.1.0] 
> ... 4 common frames omitted 
> Caused by: java.io.EOFException: null 
> at java.io.DataInputStream.readFully(DataInputStream.java:197) 
> ~[na:1.8.0_111] 
> at java.io.DataInputStream.readUTF(DataInputStream.java:609) 
> ~[na:1.8.0_111] 
> at java.io.DataInputStream.readUTF(DataInputStream.java:564) 
> ~[na:1.8.0_111] 
> at 
> org.apache.nifi.repository.schema.RecordSchema.readField(RecordSchema.java:126)
>  ~[nifi-schema-utils-1.1.0.jar:1.1.0] 
> at 
> org.apache.nifi.repository.schema.RecordSchema.readField(RecordSchema.java:144)
>  ~[nifi-schema-utils-1.1.0.jar:1.1.0] 
> at 
> org.apache.nifi.repository.schema.RecordSchema.readField(RecordSchema.java:144)
>  ~[nifi-schema-utils-1.1.0.jar:1.1.0] 
> at 
> org.apache.nifi.repository.schema.RecordSchema.readFrom(RecordSchema.java:111)
>  ~[nifi-schema-utils-1.1.0.jar:1.1.0] 
> ... 13 common frames omitted 
> {code}
> It appears that we do not properly handle Exceptions that are thrown when 
> reading the header information from a Partition file.



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

[jira] [Created] (NIFI-3705) Web Api - Use supplied group details when verifying connection creation

[Matt Gilman (JIRA)]

Matt Gilman created NIFI-3705:
-

 Summary: Web Api - Use supplied group details when verifying 
connection creation 
 Key: NIFI-3705
 URL: https://issues.apache.org/jira/browse/NIFI-3705
 Project: Apache NiFi
  Issue Type: Bug
  Components: Core Framework
Reporter: Matt Gilman
Assignee: Matt Gilman


When a connection is created, the request is verified. This verification should 
use the supplied group details to be consistent with the actual creation. 
Currently it simply searches from the root group.



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

[jira] [Updated] (NIFI-3035) URL to display a particular process group in UI

[Matt Gilman (JIRA)]

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

Matt Gilman updated NIFI-3035:
--
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> URL to display a particular process group in UI
> ---
>
> Key: NIFI-3035
> URL: https://issues.apache.org/jira/browse/NIFI-3035
> Project: Apache NiFi
>  Issue Type: New Feature
>  Components: Core UI
>Reporter: Christine Draper
>Assignee: Scott Aslan
> Fix For: 1.2.0
>
>
> Our use case has multiple teams of users working on specific process groups. 
> We would like to be able to give them a URL that will launch the UI on the 
> specific group they are working on, rather than them having to navigate to it 
> from the root group.



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

[jira] [Commented] (NIFI-3035) URL to display a particular process group in UI

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-3035:
--

Github user asfgit closed the pull request at:

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


> URL to display a particular process group in UI
> ---
>
> Key: NIFI-3035
> URL: https://issues.apache.org/jira/browse/NIFI-3035
> Project: Apache NiFi
>  Issue Type: New Feature
>  Components: Core UI
>Reporter: Christine Draper
>Assignee: Scott Aslan
> Fix For: 1.2.0
>
>
> Our use case has multiple teams of users working on specific process groups. 
> We would like to be able to give them a URL that will launch the UI on the 
> specific group they are working on, rather than them having to navigate to it 
> from the root group.



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

[jira] [Commented] (NIFI-3035) URL to display a particular process group in UI

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-3035:
--

Github user mcgilman commented on the issue:

https://github.com/apache/nifi/pull/1659
  
Thanks guys. This has been merged to master.


> URL to display a particular process group in UI
> ---
>
> Key: NIFI-3035
> URL: https://issues.apache.org/jira/browse/NIFI-3035
> Project: Apache NiFi
>  Issue Type: New Feature
>  Components: Core UI
>Reporter: Christine Draper
>Assignee: Scott Aslan
> Fix For: 1.2.0
>
>
> Our use case has multiple teams of users working on specific process groups. 
> We would like to be able to give them a URL that will launch the UI on the 
> specific group they are working on, rather than them having to navigate to it 
> from the root group.



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

[jira] [Commented] (NIFI-3035) URL to display a particular process group in UI

[ASF subversion and git services (JIRA)]

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

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

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

[NIFI-3035] use URLSearchParams .toString() to update URL. This closes #1659


> URL to display a particular process group in UI
> ---
>
> Key: NIFI-3035
> URL: https://issues.apache.org/jira/browse/NIFI-3035
> Project: Apache NiFi
>  Issue Type: New Feature
>  Components: Core UI
>Reporter: Christine Draper
>Assignee: Scott Aslan
> Fix For: 1.2.0
>
>
> Our use case has multiple teams of users working on specific process groups. 
> We would like to be able to give them a URL that will launch the UI on the 
> specific group they are working on, rather than them having to navigate to it 
> from the root group.



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

[GitHub] nifi issue #1659: [NIFI-3035] use URLSearchParams .toString() to update URL

[mcgilman]

Github user mcgilman commented on the issue:

https://github.com/apache/nifi/pull/1659
  
Thanks guys. 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 #1659: [NIFI-3035] use URLSearchParams .toString() to upda...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-3704) Add PutDatabaseRecord processor

[Matt Burgess (JIRA)]

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

Matt Burgess reassigned NIFI-3704:
--

Assignee: Matt Burgess

> Add PutDatabaseRecord processor
> ---
>
> Key: NIFI-3704
> URL: https://issues.apache.org/jira/browse/NIFI-3704
> Project: Apache NiFi
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Matt Burgess
>Assignee: Matt Burgess
>
> With the inclusion of NIFI-1280, which added Controller Services for 
> RecordReaders and RecordWriters, we could now support a processor that reads 
> records in, generates SQL statements for those records (with a specified verb 
> such as INSERT, UPDATE, DELETE, etc.), and can execute all the records in one 
> flow file as a batch. This would allow the processor to use a single 
> PreparedStatement and, for a flow file containing multiple records, would be 
> able to execute them all at once. This is in contrast to PutSQL which handles 
> batches across flow files (if fragmented transactions are enabled) or with a 
> discrete set (by taking at most a specified number of flow files at a time).
> This processor (called PutDatabaseRecord) would effectively act like the 
> combination of ConvertJSONToSQL and PutSQL, with the added features of being 
> able to take records in an arbitrary format (given that there is a 
> RecordReader implementation for that format) such as Avro, JSON, CSV, etc. 
> and execute all the statements for the flow file at once.
> Another improvement upon what can be done in ConvertJSONToSQL would be to 
> support BEGIN, COMMIT, and SQL verbs. This could be accomplished by adding an 
> AllowableValue to the dropdown, letting the user select "Use statement.type 
> Attribute". If this was selected, then the verb would be expected to be in 
> the value of the "statement.type" attribute of the incoming flow file.  Note 
> that this may supercede or deprecate the need for NIFI-3676, unless this 
> capability is also desired for that processor.
> For BEGIN and COMMIT verbs, the contents of the record(s) are not needed, as 
> the type itself should be enough to generate the appropriate SQL commands. 
> For the "SQL" Statement type, the processor could either expect the flow file 
> to contain a SQL statement (so the RecordReader would not be used), or it 
> could expect a field called "sql" that contains the SQL statement as its 
> value.



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

[jira] [Resolved] (NIFI-3703) Allow AWS processors to use DefaultAWSCredentialsProviderChain

[Joseph Gresock (JIRA)]

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

Joseph Gresock resolved NIFI-3703.
--
Resolution: Not A Problem

> Allow AWS processors to use DefaultAWSCredentialsProviderChain
> --
>
> Key: NIFI-3703
> URL: https://issues.apache.org/jira/browse/NIFI-3703
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: 1.1.1
>Reporter: Joseph Gresock
>Assignee: Joseph Gresock
>Priority: Minor
>
> Currently, the AWS processors assume that credentials must always be provided 
> to the AWS SDK constructors.  When no credentials properties are specified, 
> this causes AnonymousAWSCredentials to be used as a constructor argument to 
> the AWS client.  While this may be intended in some cases, we should also 
> allow for the option of not passing in any credentials, which causes the 
> client to use DefaultAWSCredentialsProviderChain.getInstance(), behaving as 
> specified here: 
> http://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/java-dg-roles.html



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

[jira] [Issue Comment Deleted] (NIFI-3674) Implement SiteToSiteStatusReportingTask

[Joseph Gresock (JIRA)]

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

Joseph Gresock updated NIFI-3674:
-
Comment: was deleted

(was: James Wing pointed me to this functionality in the 
AWSCredentialsProviderControllerService)

> Implement SiteToSiteStatusReportingTask
> ---
>
> Key: NIFI-3674
> URL: https://issues.apache.org/jira/browse/NIFI-3674
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Affects Versions: 1.1.1
>Reporter: Joseph Gresock
>Assignee: Joseph Gresock
>Priority: Minor
>  Labels: Site-to-Site, reporting_task, status
>
> I would like to see a reporting task similar to 
> SiteToSiteProvenanceReportingTask that sends controller status events using 
> JSON over S2S.  Since the ProcessGroupStatus object structure is recursive, 
> ideally the JSON structure would be flat, with references to parentIds 
> embedded.
> This would allow status history to be stored using any arbitrary mechanism.
> Other interesting features would include:
> * Properties to filter which components to include (Process Group, Processor, 
> Input/Output Ports, Remote Process Group, Connection)
> * Properties to filter by regex which component names or ids to include in 
> the output



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

[jira] [Commented] (NIFI-3703) Allow AWS processors to use DefaultAWSCredentialsProviderChain

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-3703:
--

Github user gresockj closed the pull request at:

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


> Allow AWS processors to use DefaultAWSCredentialsProviderChain
> --
>
> Key: NIFI-3703
> URL: https://issues.apache.org/jira/browse/NIFI-3703
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: 1.1.1
>Reporter: Joseph Gresock
>Assignee: Joseph Gresock
>Priority: Minor
>
> Currently, the AWS processors assume that credentials must always be provided 
> to the AWS SDK constructors.  When no credentials properties are specified, 
> this causes AnonymousAWSCredentials to be used as a constructor argument to 
> the AWS client.  While this may be intended in some cases, we should also 
> allow for the option of not passing in any credentials, which causes the 
> client to use DefaultAWSCredentialsProviderChain.getInstance(), behaving as 
> specified here: 
> http://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/java-dg-roles.html



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

[jira] [Updated] (NIFI-3703) Allow AWS processors to use DefaultAWSCredentialsProviderChain

[Joseph Gresock (JIRA)]

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

Joseph Gresock updated NIFI-3703:
-
Status: Open  (was: Patch Available)

James Wing pointed me to this functionality available in the 
AWSCredentialsProviderControllerService

> Allow AWS processors to use DefaultAWSCredentialsProviderChain
> --
>
> Key: NIFI-3703
> URL: https://issues.apache.org/jira/browse/NIFI-3703
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: 1.1.1
>Reporter: Joseph Gresock
>Assignee: Joseph Gresock
>Priority: Minor
>
> Currently, the AWS processors assume that credentials must always be provided 
> to the AWS SDK constructors.  When no credentials properties are specified, 
> this causes AnonymousAWSCredentials to be used as a constructor argument to 
> the AWS client.  While this may be intended in some cases, we should also 
> allow for the option of not passing in any credentials, which causes the 
> client to use DefaultAWSCredentialsProviderChain.getInstance(), behaving as 
> specified here: 
> http://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/java-dg-roles.html



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

[jira] [Updated] (NIFI-3674) Implement SiteToSiteStatusReportingTask

[Joseph Gresock (JIRA)]

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

Joseph Gresock updated NIFI-3674:
-
Status: Patch Available  (was: Reopened)

> Implement SiteToSiteStatusReportingTask
> ---
>
> Key: NIFI-3674
> URL: https://issues.apache.org/jira/browse/NIFI-3674
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Affects Versions: 1.1.1
>Reporter: Joseph Gresock
>Assignee: Joseph Gresock
>Priority: Minor
>  Labels: Site-to-Site, reporting_task, status
>
> I would like to see a reporting task similar to 
> SiteToSiteProvenanceReportingTask that sends controller status events using 
> JSON over S2S.  Since the ProcessGroupStatus object structure is recursive, 
> ideally the JSON structure would be flat, with references to parentIds 
> embedded.
> This would allow status history to be stored using any arbitrary mechanism.
> Other interesting features would include:
> * Properties to filter which components to include (Process Group, Processor, 
> Input/Output Ports, Remote Process Group, Connection)
> * Properties to filter by regex which component names or ids to include in 
> the output



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

[jira] [Resolved] (NIFI-3674) Implement SiteToSiteStatusReportingTask

[Joseph Gresock (JIRA)]

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

Joseph Gresock resolved NIFI-3674.
--
Resolution: Not A Problem

> Implement SiteToSiteStatusReportingTask
> ---
>
> Key: NIFI-3674
> URL: https://issues.apache.org/jira/browse/NIFI-3674
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Affects Versions: 1.1.1
>Reporter: Joseph Gresock
>Assignee: Joseph Gresock
>Priority: Minor
>  Labels: Site-to-Site, reporting_task, status
>
> I would like to see a reporting task similar to 
> SiteToSiteProvenanceReportingTask that sends controller status events using 
> JSON over S2S.  Since the ProcessGroupStatus object structure is recursive, 
> ideally the JSON structure would be flat, with references to parentIds 
> embedded.
> This would allow status history to be stored using any arbitrary mechanism.
> Other interesting features would include:
> * Properties to filter which components to include (Process Group, Processor, 
> Input/Output Ports, Remote Process Group, Connection)
> * Properties to filter by regex which component names or ids to include in 
> the output



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

[jira] [Reopened] (NIFI-3674) Implement SiteToSiteStatusReportingTask

[Joseph Gresock (JIRA)]

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

Joseph Gresock reopened NIFI-3674:
--

Whoops.. I resolved the wrong issue.. 

> Implement SiteToSiteStatusReportingTask
> ---
>
> Key: NIFI-3674
> URL: https://issues.apache.org/jira/browse/NIFI-3674
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Affects Versions: 1.1.1
>Reporter: Joseph Gresock
>Assignee: Joseph Gresock
>Priority: Minor
>  Labels: Site-to-Site, reporting_task, status
>
> I would like to see a reporting task similar to 
> SiteToSiteProvenanceReportingTask that sends controller status events using 
> JSON over S2S.  Since the ProcessGroupStatus object structure is recursive, 
> ideally the JSON structure would be flat, with references to parentIds 
> embedded.
> This would allow status history to be stored using any arbitrary mechanism.
> Other interesting features would include:
> * Properties to filter which components to include (Process Group, Processor, 
> Input/Output Ports, Remote Process Group, Connection)
> * Properties to filter by regex which component names or ids to include in 
> the output



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

[jira] [Updated] (NIFI-3674) Implement SiteToSiteStatusReportingTask

[Joseph Gresock (JIRA)]

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

Joseph Gresock updated NIFI-3674:
-
Status: Open  (was: Patch Available)

James Wing pointed me to this functionality in the 
AWSCredentialsProviderControllerService

> Implement SiteToSiteStatusReportingTask
> ---
>
> Key: NIFI-3674
> URL: https://issues.apache.org/jira/browse/NIFI-3674
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Affects Versions: 1.1.1
>Reporter: Joseph Gresock
>Assignee: Joseph Gresock
>Priority: Minor
>  Labels: Site-to-Site, reporting_task, status
>
> I would like to see a reporting task similar to 
> SiteToSiteProvenanceReportingTask that sends controller status events using 
> JSON over S2S.  Since the ProcessGroupStatus object structure is recursive, 
> ideally the JSON structure would be flat, with references to parentIds 
> embedded.
> This would allow status history to be stored using any arbitrary mechanism.
> Other interesting features would include:
> * Properties to filter which components to include (Process Group, Processor, 
> Input/Output Ports, Remote Process Group, Connection)
> * Properties to filter by regex which component names or ids to include in 
> the output



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

[GitHub] nifi pull request #1671: NIFI-3703: Adding 'Allow Anonymous Credentials' pro...

[gresockj]

Github user gresockj closed the pull request at:

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


---
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-3686) EOFException on swap in causes tight loop in polling for flowfiles

[Mark Payne (JIRA)]

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

Mark Payne commented on NIFI-3686:
--

[~mosermw] The FileSystemSwapManager writes the contents of a swap file to a 
temp file, then performs an fsync, and finally renames the file. So there 
should be no way to get an EOFException unless the file in actually corrupt - 
it should not be due to the contents not being completely written out. I tried 
to replicate the behavior locally by creating a 100 MB partition and putting 
the FlowFile repo there, but I wasn't able to replicate. So just saying that, 
to say that there may be more to this story than simply running out of disk 
space and not being able to finish writing the file.

In any case, though, I think when we are swapping it in, we should not assume 
that an EOFException would dictate that we can lose all FlowFiles. We need to 
ensure that we are able to recover those FlowFiles that we can. Unfortunately, 
looking at it now, it looks like the schema that we are using has a single 
element named "FlowFiles" and the Swap File is expected to consist of a single 
"Record." We'd need to update the schema so that it allows each FlowFile to be 
written as a separate Record. The downside is that the schema would be 
incompatible. So we could still remain backward compatible but would lost 
"forward compatibility" -- meaning that if a Swap File gets written in the new 
format we won't be able to recover that swap file if we rolled back to an old 
version of NiFi...

> EOFException on swap in causes tight loop in polling for flowfiles
> --
>
> Key: NIFI-3686
> URL: https://issues.apache.org/jira/browse/NIFI-3686
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.1.1
>Reporter: Michael Moser
>
> If flowfile_repository partition fills 100% while swapping files out to a new 
> swap file, then this swap file becomes corrupt (partially written).  When 
> NiFi tries to swap this file in, EOFException happens and we get following 
> ERROR, which is nice.
> 2017-04-10 18:02:58,855 ERROR [Timer-Driven Process Thread-3] 
> o.a.n.controller.StandardFlowFileQueue Failed to swap in FlowFiles from Swap 
> File 
> /local/mwmoser/nifi-1.2.0-SNAPSHOT/./flowfile_repository/swap/1491574631605-2840b630-57fc-4f49-615b-0b37d77bec66-5dbc0ad0-921c-483e-a05d-5c65d014fa48.swap;
>  Swap File appears to be corrupt!
> However, once all other dataflow stops, the queue now shows 1 flowfiles 
> in it.  The processor reading from this queue constantly has its onTrigger() 
> called, and session.get() polls the queue and gets 0 files returned.  This 
> happens in a tight loop, with no other errors.
> To a user it appears that the processor is doing lots of work but just not 
> processing those 1 files.  The error message above only appears once in 
> the nifi-app.log, so you don't see anything wrong if you tail the log. 
>  When you restart NiFi, the error message above appears again, but the user 
> experience of 1 files not processing remains.
> The new SchemaSwapDeserializer does not (and perhaps cannot) implement the 
> IncompleteSwapFileException that the old SimpleSwapDeserializer does.  So, 
> reading a swap file is currently all-or-nothing.



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

[jira] [Created] (NIFI-3704) Add PutDatabaseRecord processor

[Matt Burgess (JIRA)]

Matt Burgess created NIFI-3704:
--

 Summary: Add PutDatabaseRecord processor
 Key: NIFI-3704
 URL: https://issues.apache.org/jira/browse/NIFI-3704
 Project: Apache NiFi
  Issue Type: New Feature
  Components: Extensions
Reporter: Matt Burgess


With the inclusion of NIFI-1280, which added Controller Services for 
RecordReaders and RecordWriters, we could now support a processor that reads 
records in, generates SQL statements for those records (with a specified verb 
such as INSERT, UPDATE, DELETE, etc.), and can execute all the records in one 
flow file as a batch. This would allow the processor to use a single 
PreparedStatement and, for a flow file containing multiple records, would be 
able to execute them all at once. This is in contrast to PutSQL which handles 
batches across flow files (if fragmented transactions are enabled) or with a 
discrete set (by taking at most a specified number of flow files at a time).

This processor (called PutDatabaseRecord) would effectively act like the 
combination of ConvertJSONToSQL and PutSQL, with the added features of being 
able to take records in an arbitrary format (given that there is a RecordReader 
implementation for that format) such as Avro, JSON, CSV, etc. and execute all 
the statements for the flow file at once.

Another improvement upon what can be done in ConvertJSONToSQL would be to 
support BEGIN, COMMIT, and SQL verbs. This could be accomplished by adding an 
AllowableValue to the dropdown, letting the user select "Use statement.type 
Attribute". If this was selected, then the verb would be expected to be in the 
value of the "statement.type" attribute of the incoming flow file.  Note that 
this may supercede or deprecate the need for NIFI-3676, unless this capability 
is also desired for that processor.

For BEGIN and COMMIT verbs, the contents of the record(s) are not needed, as 
the type itself should be enough to generate the appropriate SQL commands. For 
the "SQL" Statement type, the processor could either expect the flow file to 
contain a SQL statement (so the RecordReader would not be used), or it could 
expect a field called "sql" that contains the SQL statement as its value.



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

[GitHub] nifi-site pull request #17: MiNiFi-260: Create a "Getting Started" Guide for...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/nifi-site/pull/17


---
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-site pull request #17: MiNiFi-260: Create a "Getting Started" Guide for...

[apiri]

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

https://github.com/apache/nifi-site/pull/17#discussion_r111404358
  
--- Diff: src/pages/markdown/minifi/getting-started.md ---
@@ -0,0 +1,122 @@
+---
+title: Apache NiFi MiNiFi: Getting Started
+---
+
+# Getting started with MiNiFi
+
+This page explains how to configure and deploy MiNiFi agents.
+
+The Java agent is able to run most of [NiFi's available 
processors](http://nifi.apache.org/docs.html), but is a larger binary 
distribution (49MB) and consumes greater system resources (24MB max JVM 
heapsize by default). If you need maximum flexibility to make routing and 
processing decisions at your data's point of origin, the Java agent is a good 
fit.
+
+The C++ agent is a smaller binary (3.2MB), consumes low system memory 
(about 5MB at idle) but has [a limited subset of 
processors](https://github.com/apache/nifi-minifi-cpp#caveats). If your primary 
concern is gathering and pushing data to downstream consumers and minimizing 
system impact, the C++ agent is a good fit.
+
+
+1. Install the appropriate OS level dependencies:
+
+   MiNiFi Java:
+
+  - Java 1.8+
+
+   MiNiFi C++:
--- End diff --

@randerzander totally fair point. certainly messed up mapping items between 
the current release and master.  From that standpoint, I am on board.  We (as 
in the community at large) should think about how to make this process a bit 
smoother in terms of releases and the site, but that is a concern for another 
issue and effort.


---
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-3686) EOFException on swap in causes tight loop in polling for flowfiles

[Michael Moser (JIRA)]

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

Michael Moser commented on NIFI-3686:
-

After manually removing the corrupt swap file, NiFi seems to never forget that 
it was there.  Once I let all flowfiles drain from the system, and restart 
NiFi, WriteAheadFlowFileRepository continues to believe it has 1 swap file out 
there.

INFO [pool-9-thread-1] org.wali.MinimalLockingWriteAheadLog 
org.wali.MinimalLockingWriteAheadLog@775429c8 checkpointed with 0 Records and 1 
Swap Files in 48 milliseconds (Stop-the-world time = 23 milliseconds, Clear 
Edit Logs time = 15 millis), max Transaction ID 50011


> EOFException on swap in causes tight loop in polling for flowfiles
> --
>
> Key: NIFI-3686
> URL: https://issues.apache.org/jira/browse/NIFI-3686
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.1.1
>Reporter: Michael Moser
>
> If flowfile_repository partition fills 100% while swapping files out to a new 
> swap file, then this swap file becomes corrupt (partially written).  When 
> NiFi tries to swap this file in, EOFException happens and we get following 
> ERROR, which is nice.
> 2017-04-10 18:02:58,855 ERROR [Timer-Driven Process Thread-3] 
> o.a.n.controller.StandardFlowFileQueue Failed to swap in FlowFiles from Swap 
> File 
> /local/mwmoser/nifi-1.2.0-SNAPSHOT/./flowfile_repository/swap/1491574631605-2840b630-57fc-4f49-615b-0b37d77bec66-5dbc0ad0-921c-483e-a05d-5c65d014fa48.swap;
>  Swap File appears to be corrupt!
> However, once all other dataflow stops, the queue now shows 1 flowfiles 
> in it.  The processor reading from this queue constantly has its onTrigger() 
> called, and session.get() polls the queue and gets 0 files returned.  This 
> happens in a tight loop, with no other errors.
> To a user it appears that the processor is doing lots of work but just not 
> processing those 1 files.  The error message above only appears once in 
> the nifi-app.log, so you don't see anything wrong if you tail the log. 
>  When you restart NiFi, the error message above appears again, but the user 
> experience of 1 files not processing remains.
> The new SchemaSwapDeserializer does not (and perhaps cannot) implement the 
> IncompleteSwapFileException that the old SimpleSwapDeserializer does.  So, 
> reading a swap file is currently all-or-nothing.



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

[jira] [Commented] (NIFI-3673) Loads the different class in classloader when Bumping NAR plugin

[Bryan Bende (JIRA)]

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

Bryan Bende commented on NIFI-3673:
---

[~combine] Thank you for verifying the original problem. If you are seeing 
something else then this JIRA should be closed and a new JIRA for the new 
problem should be created.

Did you have success using the native library in previous versions of NiFi and 
now it doesn't work on master? or is this the first time you are trying it? 
 

> Loads the different class in classloader when Bumping NAR plugin
> 
>
> Key: NIFI-3673
> URL: https://issues.apache.org/jira/browse/NIFI-3673
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Reporter: Byunghwa Yun
>Assignee: Bryan Bende
> Fix For: 1.2.0
>
>
> When I use master branch, Hadoop processor throws the exception related 
> ClassLoader.
> 2017-04-05 17:58:47,391 ERROR [StandardProcessScheduler Thread-1] 
> o.a.n.controller.StandardProcessorNode Failed to invoke @OnScheduled method 
> due to java.lang.RuntimeException: Failed while executing one of processor's 
> OnScheduled task.
> java.lang.RuntimeException: Failed while executing one of processor's 
> OnScheduled task.
> at 
> org.apache.nifi.controller.StandardProcessorNode.invokeTaskAsCancelableFuture(StandardProcessorNode.java:1466)
>  ~[na:na]
> at 
> org.apache.nifi.controller.StandardProcessorNode.access$000(StandardProcessorNode.java:98)
>  ~[na:na]
> at 
> org.apache.nifi.controller.StandardProcessorNode$1.run(StandardProcessorNode.java:1287)
>  ~[na:na]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_101]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> [na:1.8.0_101]
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>  [na:1.8.0_101]
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
>  [na:1.8.0_101]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [na:1.8.0_101]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_101]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_101]
> Caused by: java.util.concurrent.ExecutionException: 
> java.lang.reflect.InvocationTargetException
> at java.util.concurrent.FutureTask.report(FutureTask.java:122) 
> [na:1.8.0_101]
> at java.util.concurrent.FutureTask.get(FutureTask.java:206) 
> [na:1.8.0_101]
> at 
> org.apache.nifi.controller.StandardProcessorNode.invokeTaskAsCancelableFuture(StandardProcessorNode.java:1449)
>  ~[na:na]
> ... 9 common frames omitted
> Caused by: java.lang.reflect.InvocationTargetException: null
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
> ~[na:1.8.0_101]
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
> ~[na:1.8.0_101]
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  ~[na:1.8.0_101]
> at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_101]
> at 
> org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:137)
>  ~[na:na]
> at 
> org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:125)
>  ~[na:na]
> at 
> org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:70)
>  ~[na:na]
> at 
> org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotation(ReflectionUtils.java:47)
>  ~[na:na]
> at 
> org.apache.nifi.controller.StandardProcessorNode$1$1.call(StandardProcessorNode.java:1291)
>  ~[na:na]
> at 
> org.apache.nifi.controller.StandardProcessorNode$1$1.call(StandardProcessorNode.java:1287)
>  ~[na:na]
> ... 6 common frames omitted
> Caused by: java.lang.RuntimeException: java.lang.RuntimeException: class 
> org.apache.hadoop.security.JniBasedUnixGroupsMappingWithFallback not 
> org.apache.hadoop.security.GroupMappingServiceProvider
> at 
> org.apache.hadoop.conf.Configuration.getClass(Configuration.java:2231) 
> ~[na:na]
> at org.apache.hadoop.security.Groups.(Groups.java:78) ~[na:na]
> at org.apache.hadoop.security.Groups.(Groups.java:74) ~[na:na]
> at 
> org.apache.hadoop.security.Groups.getUserToGroupsMappingService(Groups.java:303)
>  ~[na:na]
> at 
> org.apache.hadoop.security.UserGroupInformation.initialize(UserGroupInformation.java:283)
>  ~[na:na]
> at 
> 

[jira] [Updated] (NIFI-3700) Create Sqoop processor

[Joseph Petro (JIRA)]

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

Joseph Petro updated NIFI-3700:
---
Summary: Create Sqoop processor  (was: sqoop processor)

> Create Sqoop processor
> --
>
> Key: NIFI-3700
> URL: https://issues.apache.org/jira/browse/NIFI-3700
> Project: Apache NiFi
>  Issue Type: New Feature
>Reporter: Joseph Petro
>Priority: Minor
>
> A sqoop processor should be added. Sqoop is powerful for data ingestion and 
> export.



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

[jira] [Commented] (NIFI-3703) Allow AWS processors to use DefaultAWSCredentialsProviderChain

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-3703:
--

GitHub user gresockj opened a pull request:

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

NIFI-3703: Adding 'Allow Anonymous Credentials' property to AWS processors

Thank you for submitting a contribution to Apache NiFi.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [x] Is there a JIRA ticket associated with this PR? Is it referenced 
 in the commit message?

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

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

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

### For code changes:
- [x] Have you ensured that the full suite of tests is executed via mvn 
-Pcontrib-check clean install at the root nifi folder?
- [x] Have you written or updated unit tests to verify your changes?
- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)? 
- [ ] If applicable, have you updated the LICENSE file, including the main 
LICENSE file under nifi-assembly?
- [ ] If applicable, have you updated the NOTICE file, including the main 
NOTICE file found under nifi-assembly?
- [ ] If adding new Properties, have you added .displayName in addition to 
.name (programmatic access) for each of the new properties?

### For documentation related changes:
- [ ] Have you ensured that format looks appropriate for the output in 
which it is rendered?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and submit an update to your PR as soon as possible.


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

$ git pull https://github.com/gresockj/nifi NIFI-3703

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

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


commit 12c1f52d008af07c81c8e995c96be1b474d5de8f
Author: Joe Gresock 
Date:   2017-04-13T11:32:27Z

NIFI-3703: Adding 'Allow Anonymous Credentials' property to AWS processors




> Allow AWS processors to use DefaultAWSCredentialsProviderChain
> --
>
> Key: NIFI-3703
> URL: https://issues.apache.org/jira/browse/NIFI-3703
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: 1.1.1
>Reporter: Joseph Gresock
>Priority: Minor
>
> Currently, the AWS processors assume that credentials must always be provided 
> to the AWS SDK constructors.  When no credentials properties are specified, 
> this causes AnonymousAWSCredentials to be used as a constructor argument to 
> the AWS client.  While this may be intended in some cases, we should also 
> allow for the option of not passing in any credentials, which causes the 
> client to use DefaultAWSCredentialsProviderChain.getInstance(), behaving as 
> specified here: 
> http://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/java-dg-roles.html



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

[jira] [Assigned] (NIFI-3703) Allow AWS processors to use DefaultAWSCredentialsProviderChain

[Joseph Gresock (JIRA)]

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

Joseph Gresock reassigned NIFI-3703:


Assignee: Joseph Gresock

> Allow AWS processors to use DefaultAWSCredentialsProviderChain
> --
>
> Key: NIFI-3703
> URL: https://issues.apache.org/jira/browse/NIFI-3703
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: 1.1.1
>Reporter: Joseph Gresock
>Assignee: Joseph Gresock
>Priority: Minor
>
> Currently, the AWS processors assume that credentials must always be provided 
> to the AWS SDK constructors.  When no credentials properties are specified, 
> this causes AnonymousAWSCredentials to be used as a constructor argument to 
> the AWS client.  While this may be intended in some cases, we should also 
> allow for the option of not passing in any credentials, which causes the 
> client to use DefaultAWSCredentialsProviderChain.getInstance(), behaving as 
> specified here: 
> http://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/java-dg-roles.html



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

[jira] [Updated] (NIFI-3703) Allow AWS processors to use DefaultAWSCredentialsProviderChain

[Joseph Gresock (JIRA)]

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

Joseph Gresock updated NIFI-3703:
-
Status: Patch Available  (was: Open)

> Allow AWS processors to use DefaultAWSCredentialsProviderChain
> --
>
> Key: NIFI-3703
> URL: https://issues.apache.org/jira/browse/NIFI-3703
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: 1.1.1
>Reporter: Joseph Gresock
>Assignee: Joseph Gresock
>Priority: Minor
>
> Currently, the AWS processors assume that credentials must always be provided 
> to the AWS SDK constructors.  When no credentials properties are specified, 
> this causes AnonymousAWSCredentials to be used as a constructor argument to 
> the AWS client.  While this may be intended in some cases, we should also 
> allow for the option of not passing in any credentials, which causes the 
> client to use DefaultAWSCredentialsProviderChain.getInstance(), behaving as 
> specified here: 
> http://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/java-dg-roles.html



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

[GitHub] nifi pull request #1671: NIFI-3703: Adding 'Allow Anonymous Credentials' pro...

[gresockj]

GitHub user gresockj opened a pull request:

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

NIFI-3703: Adding 'Allow Anonymous Credentials' property to AWS processors

Thank you for submitting a contribution to Apache NiFi.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [x] Is there a JIRA ticket associated with this PR? Is it referenced 
 in the commit message?

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

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

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

### For code changes:
- [x] Have you ensured that the full suite of tests is executed via mvn 
-Pcontrib-check clean install at the root nifi folder?
- [x] Have you written or updated unit tests to verify your changes?
- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)? 
- [ ] If applicable, have you updated the LICENSE file, including the main 
LICENSE file under nifi-assembly?
- [ ] If applicable, have you updated the NOTICE file, including the main 
NOTICE file found under nifi-assembly?
- [ ] If adding new Properties, have you added .displayName in addition to 
.name (programmatic access) for each of the new properties?

### For documentation related changes:
- [ ] Have you ensured that format looks appropriate for the output in 
which it is rendered?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and submit an update to your PR as soon as possible.


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

$ git pull https://github.com/gresockj/nifi NIFI-3703

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

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


commit 12c1f52d008af07c81c8e995c96be1b474d5de8f
Author: Joe Gresock 
Date:   2017-04-13T11:32:27Z

NIFI-3703: Adding 'Allow Anonymous Credentials' property to AWS processors




---
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-3703) Allow AWS processors to use DefaultAWSCredentialsProviderChain

[Joseph Gresock (JIRA)]

Joseph Gresock created NIFI-3703:


 Summary: Allow AWS processors to use 
DefaultAWSCredentialsProviderChain
 Key: NIFI-3703
 URL: https://issues.apache.org/jira/browse/NIFI-3703
 Project: Apache NiFi
  Issue Type: Improvement
  Components: Extensions
Affects Versions: 1.1.1
Reporter: Joseph Gresock
Priority: Minor


Currently, the AWS processors assume that credentials must always be provided 
to the AWS SDK constructors.  When no credentials properties are specified, 
this causes AnonymousAWSCredentials to be used as a constructor argument to the 
AWS client.  While this may be intended in some cases, we should also allow for 
the option of not passing in any credentials, which causes the client to use 
DefaultAWSCredentialsProviderChain.getInstance(), behaving as specified here: 
http://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/java-dg-roles.html



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

[jira] [Commented] (NIFI-3673) Loads the different class in classloader when Bumping NAR plugin

[Byunghwa Yun (JIRA)]

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

Byunghwa Yun commented on NIFI-3673:


[~bende] It's working. Thanks for your efforts.
But I got the another classloader problem. NiFi doesn't load the hadoop native 
library.
I attach the log. Thank you.

2017-04-13 16:49:26,430 DEBUG [StandardProcessScheduler Thread-6] 
org.apache.hadoop.util.NativeCodeLoader Trying to load the custom-built 
native-hadoop library...
2017-04-13 16:49:26,430 DEBUG [StandardProcessScheduler Thread-6] 
org.apache.hadoop.util.NativeCodeLoader Failed to load native-hadoop with 
error: java.lang.UnsatisfiedLinkError: Native Library 
/home/hadoop/hadoop-2.6.0-cdh5.5.1/lib/native/libhadoop.so already loaded in 
another classloader
2017-04-13 16:49:26,430 DEBUG [StandardProcessScheduler Thread-6] 
org.apache.hadoop.util.NativeCodeLoader 
java.library.path=/home/hadoop/hdfs/lib/native
2017-04-13 16:49:26,430 WARN [StandardProcessScheduler Thread-6] 
org.apache.hadoop.util.NativeCodeLoader Unable to load native-hadoop library 
for your platform... using builtin-java classes where applicable


> Loads the different class in classloader when Bumping NAR plugin
> 
>
> Key: NIFI-3673
> URL: https://issues.apache.org/jira/browse/NIFI-3673
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Reporter: Byunghwa Yun
>Assignee: Bryan Bende
> Fix For: 1.2.0
>
>
> When I use master branch, Hadoop processor throws the exception related 
> ClassLoader.
> 2017-04-05 17:58:47,391 ERROR [StandardProcessScheduler Thread-1] 
> o.a.n.controller.StandardProcessorNode Failed to invoke @OnScheduled method 
> due to java.lang.RuntimeException: Failed while executing one of processor's 
> OnScheduled task.
> java.lang.RuntimeException: Failed while executing one of processor's 
> OnScheduled task.
> at 
> org.apache.nifi.controller.StandardProcessorNode.invokeTaskAsCancelableFuture(StandardProcessorNode.java:1466)
>  ~[na:na]
> at 
> org.apache.nifi.controller.StandardProcessorNode.access$000(StandardProcessorNode.java:98)
>  ~[na:na]
> at 
> org.apache.nifi.controller.StandardProcessorNode$1.run(StandardProcessorNode.java:1287)
>  ~[na:na]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_101]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> [na:1.8.0_101]
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>  [na:1.8.0_101]
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
>  [na:1.8.0_101]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [na:1.8.0_101]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_101]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_101]
> Caused by: java.util.concurrent.ExecutionException: 
> java.lang.reflect.InvocationTargetException
> at java.util.concurrent.FutureTask.report(FutureTask.java:122) 
> [na:1.8.0_101]
> at java.util.concurrent.FutureTask.get(FutureTask.java:206) 
> [na:1.8.0_101]
> at 
> org.apache.nifi.controller.StandardProcessorNode.invokeTaskAsCancelableFuture(StandardProcessorNode.java:1449)
>  ~[na:na]
> ... 9 common frames omitted
> Caused by: java.lang.reflect.InvocationTargetException: null
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
> ~[na:1.8.0_101]
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
> ~[na:1.8.0_101]
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  ~[na:1.8.0_101]
> at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_101]
> at 
> org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:137)
>  ~[na:na]
> at 
> org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:125)
>  ~[na:na]
> at 
> org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:70)
>  ~[na:na]
> at 
> org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotation(ReflectionUtils.java:47)
>  ~[na:na]
> at 
> org.apache.nifi.controller.StandardProcessorNode$1$1.call(StandardProcessorNode.java:1291)
>  ~[na:na]
> at 
> org.apache.nifi.controller.StandardProcessorNode$1$1.call(StandardProcessorNode.java:1287)
>  ~[na:na]
> ... 6 common frames omitted
> Caused by: java.lang.RuntimeException: