@MattWho  Just for information. This originally described phenomen is solved in the combination NiFi 1.11.1 and NiFi-Registry 0.5.0. A versioncontrolled process-group which contains disabled processors isn't marked anymore with containing "uncommitted changes" after restart of NiFi. Only thing that struck me but isn't a problem: If I disable a versioncontrolled process-group this doesn't lead to marking the process group as having "uncommited changes". But after restart of NiFi this process group is marked as having "uncommited changes". The option "Show local changes" names the differences as "Processor was disabled" for all components within the process group.Now I can proceed a commit and everything stays fine after restart of NiFi. ... View more

@MattWho really appreciate you for educating me on this. Thanks! ... View more

@MattWho Thank you once again for the information posted here. It solved our problem.    I was able to run the flow in another cluster using nifi.sh instead of running it with ambari (and the encrypt tool it uses).   copying nifi.sensitive.props.key in /etc/nifi/conf/nifi.properties from source cluster did the trick.    BR, David     ... View more

thanks @MattWho ... View more

Thanks for your reply. This solution worked. ... View more

Thank you for sharing your thoughts around this integration, it really really helps. I will try to do a POC based out of your suggestion ... View more

@Sush217    First thing i noticed here is that it appears that your are trying to start all three NiFi nodes on a single Windows machine.  Why?  You just add overhead with three NiFi nodes on one server.  Typical NiFi cluster setups are one NiFi instance per server. The NiFi properties file would need to be unique per each NiFi instance.  They cannot share any binding ports in common since only one node is going to be able to bind to a given port number. This includes properties like: nifi.remote.input.socket.port= nifi.web.http.port= or nifi.web.https.port= (if secured) nifi.cluster.node.protocol.port= the configured NiFi hostname also needs to be resolvable.  You are using node1, node2, and node3.  Since all your NiFI nodes are running on the same Windows server, those would all need to be resolvable to the Windows server IP or you could use same hostname for all three instance since they are running on the same host. Now you are also trying to use the embedded zookeeper which means each instance us going to try to standup and start its own zookeeper node.  So just like NiFi, these zookeeper nodes can not share the same port numbers.  So each cannot be configured to use 2181, 2888, and 3888.  Plus, just like NiFi, the hostnames node1, node 2, and node 3 would all need to be resolvable in DNS or the windows local hosts file.  Also not ideal to have multiple zookeeper nodes running on the same server.   If you looking to just play around with NiFi, you should just install a standalone instance of NiFi, or setup a single node cluster.  You can always add additional nodes to your 1 node cluster later by setting up additional servers with NiFi. As you have it configured currently, my guess here is that if you parse through the nifi-app.log for each of your nodes, you are going to see errors related to resolving each your node hostnames to IPs and then later see address already in use errors. Hope this helps, Matt ... View more

@Sush217    This thread/topic is very old and has an accepted answer.  Please start a new question/topic wit your query. We'll be happy to assist you.   Matt ... View more

@RAM17    The rest-api call you are making will not download the content of a FlowFile. A NiFi FlowFile consists of two parts: 1. FlowFile Attributes/metadata 2. FlowFile content You are looking to download the content of a FlowFile. NiFi does not track FlowFiles using the "filename".  NiFi only tracks FlowFiles by there assigned uuid.  So passing the filename "9b3c4f34-ad98-4835-9412-94228db3adab.0.csv" is not going to result in content being returned. Using the NiFi rest-api to retrieve the content of a FlowFile from a connection queue is a multi step process. Step 1:  Make a queue listing request curl -X POST `http://localhost:8080/nifi-api/flowfile-queues/2dc8fdee-0170-1000-768a-ea14bc96a9cd/listing-requests` The json response will contain the listing request "id" which will be a uuid which will use in next rest-api call to get a listing of the FlowFIles in this queue. Step 2: Get list of FlowFiles created by above request. curl `http://localhost:8080/nifi-api/flowfile-queues/2dc8fdee-0170-1000-768a-ea14bc96a9cd/<listing request id>` Above will return json with the list of FlowFiles in the connection queue found under "flowFileSummaries" which will include following attributes for each FlowFile: --- "uri" rest-api uri for the flowfile --- "uuid" the UUID for the FlowFile (also found in above uri) --- "filename" filename attribute for flowfile  associated to above UUID. --- "position", "size", "queuedDuration", "lineageDuration", "penaltyExpiresIn", "clusterNodeId", "clusterNodeAddress", "penalized"   Step 3: Use the uri for the flowfile you want to retrieve the flowfile content from curl `http://localhost:8080/nifi-api/flowfile-queues/2dc8fdee-0170-1000-768a-ea14bc96a9cd/flowfiles/<flowfile uuid>/content` Performing above rest-api call without "/content" on the end will retrieve the FlowFile metadata instead of the content.  You also may want to redirect the response to above rest-api call to a file on local disk using the "filename" attribute returned during step 2.   Also keep in mind that you can only download the content of a FlowFile from a queue if that FlowFile is still in the connection queue.  If downstream processors are running and process that FlowFile from the connection queue, it will not be available any longer to download from that queue.   If you found this answer your query, please take a moment to accept the response.   Hope this helps, Matt   ... View more

Thanks @MattWho .. Joe Asked me to build using PR# 4045, and test it... M on it to verify if it fixed the issue...  Will let you know...  Thanks for your help.. ... View more