@girish6    By xml file, I am assuming you are referring to the flow.xml.gz file? NiFi will only read the flow.xml.gz file during NiFi startup.  While NiFi is running the flow.xml resides completely in JVM heap memory and updates made via the UI or rest-api calls are pushed to flow.xml.gz only. It can be very dangerous manually editing the flow.xml.gz file and is not recommended.  Your queued FlowFiles are tightly coupled  to specific connection uuids.  While the NiFI UI/rest-api would block you from removing a connection which has queued FlowFiles, the flow.xml.gz would not offer such protections.  This could result in data loss if someone where to manually edit the flow.xml.gz file and restart NiFi.   Also keep in mind that in a multi-node NiFi cluster each node runs with its own copy of the flow.xml.gz loaded in to memory and the UI and rest-api calls are replicated to all nodes to make sure these files stay synced across your cluster.   Hope this helps, Matt ... View more

@xpelive    Just want to make sure a couple configurations. 1. The port you are using in the URL (8180) is the "nifi.web.http.port=" and not the "nifi.remote.input.socket.port=" port configured in your nifi.properties file. 2. When you start your NiFi instance, you will see a line output in the nifi-app.log when startup is complete that says the NiFi Ui is available at the following URLs:  Is "localhost:8180" listed in one of those URLs?  If not, you need to use one of the URLs listed in your Remote Process Group.  It might be that localhost is bound to a different NIC on your server than what NiFi is listening on. 3. If you have or will ever have more than 1 NiFi node in a NiFi cluster, using "localhost" is not going to work.  Your NiFi nodes should be configured to use the actual hostnames fo the server on which the service is running.  That hostname should be configured in both these properties: --- nifi.remote.input.host= --- nifi.web.http.host=   4. Since your NiFi is not secured, make sure that your nifi.properties file is not configured to be secure: nifi.remote.input.secure=false.     Null exceptions are particularly difficult to diagnose because a null basically means there was no error handling coded to handle to particular exception.  Thus we need o look at all angles of the configuration to see where the issue may reside. ... View more

@Biswa    Your "Replacement Value" is set to "$1". This means that the replacement value is the value associated to the first java regex capture group found in your configured "Search Value".  The issue is your "Search value" contains no capture groups.   Perhaps providing a sample input content and desired output content would help here. Hope this helps you, Matt   ... View more

@xpelive    For site-to-site, NiFi attempts to create peers files inside a "state" directory within the NiFi conf directory. These peers files allow a NiFi instance to share peer information across multiple identical S2S connections (like having multiple Remote Process Groups (RPGs) all configured with same target URL(s)).  This helps reduce overhead associated with every identical instance of S2S retrieving the same details form the same target. It sounds like your S2S connection is working and the peers info is being returned, but it is unable to store that peer information locally. This is why your S2S connection still works even though this peers bulletin is being thrown. I would suggest you make sure a "state" directory exists within NiFi's conf directory and the NiFi service user (user that owns the NiFi java process) has proper ownership and permissions to navigate that full directory path and read/write to that directory. Hope this helps you, Matt   ... View more