@AlokKumar  NiFi authorization policies are very granular. A user will not have access to flow development icon across top of the UI unless that user is authorized within the currently access process group to "modify the component", but you would also want those same users to also be authorized for "view the component".  Now depending on what additional access you want each user to have, you'll probably be authorizing them for even more NiFi policies.  Keep in mind that by adding a user to the "modify the component" authorization policy in the "Copy of ProcessGroupAdminTest" process group will only give that user the ability to add and modify components within that process group and any child/sub process group of "Copy of ProcessGroupAdminTest" Process group (if a child/sub process group is not inheriting authorizations from the parent Process group, then user you add to parent would not have same access to chid/sub Process group). NiFi has "Global Access Policies" and "Component Access Policies" The Global Access Policies are set by accessing the NiFi Global menu (three horizontal lines in upper right corner of the NiFi UI) and then "Policies". If you hover your cursor over the access policy, it will pop-up a description of what the policy grants access for: The levels of access you want to provide your individual users/teams is completely up to you.  ALL users must be authorized for the "View the User Interface" global access policy in order to access the NiFi UI, but that does not give the user much access beyond that.   So you need to decide which user will be building dataflows, NiFi refers to them as DataFlow Managers (DFM)s.   Then you may also have operators which you only grant ability to "view the component" and "operate the component" certain dataflows with no authorization to modify or view the data. The component level access policies are set by clicking on the "key" icon for a selected component.  For example: Below I have clicked on the "GenerateFlowFile" processor as we can see it in the "operation" panel to its left.  Inside that Operate panel, your admin user (or other users you have authorized) will have access to the policies for that component.   Granting a user "view the component" and "modify the component" on a process group will give that user the ability to build and operate dataflows.  But that user will still not be authorized to view the content of the FlowFiles traversing that dataflow, empty a connection queue, or view the provenance data produced by those components unless you set that additional authorizations.      Please help our community grow. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more

@Bern this is your new question without a accepted solution.  So a bit confused by your last response. Matt ... View more

@AlokKumar  NiFi allows very granular authorizations down to the individual component.  A component such as a processor will inherit its authorizations from the Process Group in which it resides, IF there are no explicit policies set directly in the processor itself.  Likewise, a Process group will inherit it's authorization from it's parent Process Group if it does not have explicit policies set directly on that child process group. When you launch NiFi for the very first time, NiFi will create the root Process Group for you and it will have the name "NiFi Flow".  It is the UI canvas you see when you access the UI.  Form the second image you shared we can see that you have access the "policies" for a child process group named "Copy of ProcessGroupAdminTest".   What we can also see from this is that it is inheriting the "view the component" policy from the root process group "NiFi Flow":  This is why you will see the add user and delete options as greyed out.  You need to first click "override" and choose either to start with no users or copy the current authorized users.  After doing this you will be able to add additional user to this policy on this child process group. Keep in mind that once you override inheritance on this components policy(s), inheritance no longer applies to this component.  Any changes to the policies set on the parent Process Group "NiFi Flow" will not get applied to this child Process Group. Please help our community grow. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more

@asand3r  JVM Garbage collection is stop-the-world which would prevent for the duration of that GC event  the Kafka clients from communicating with Kafka. If that duration of pause is long enough I could cause Kafka to do a rebalance.  I can't say that you are experiencing that .   Maybe put the consumeKafka processor class in INFO level logging and monitor the nifi-app.log for any indication of rebalance happening. When it comes GC pauses, a common mistake I see is individuals setting the JVM heap settings in NiFi way to high simply because the server on which they have in stalled NiFi has a lot of installed memory.   Since GC only happens once the allocated JVM memory utilization reaches around 80%, large heaps could lead to long stop-the-world if there is a lot top clean-up to do.   Please help our community grow. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more