@davehkd  Unfortunately, I would need to have access to the nifi-app.log file(s) from each node to dig in deeper. Did you copy the flow.xml.gz,  flow.json.gz, users.xml, and authorizations.xml files from NiFi node 1 or 2 to NIFi node 3?  These files all need to match in order for a node to join the cluster.   1. The UI of nifi1 or nifi2  shows "2/2" in the status bar just along top of canvas? 2. The UI of nifi3 shows "1/1" in the status bar just along the top of the canvas? If both above are true, this indicates nifi3 is member of a different cluster. Possible result if issue with your ZK or using a different ZK root node (nifi.zookeeper.root.node).  Check for any leading or trailing whitespace in your configuration. You may also want to inspect your ZK logs for the connections coming from all three nodes. If you found that the provided solution(s) assisted you with your query, please take a moment to login and click Accept as Solution below each response that helped. Matt ... View more

@GSB  If you wanted it always to be two digits, you would need to apply the same if/else NiFi Expression Language (NEL) logic the minute calculations in the working solution provided by @cotopaul  ${value:divide(3600):lt(10):ifElse(${value:divide(3600):prepend(0)},${value:divide(3600)})}:${value:divide(60):mod(60):lt(10):ifElse(${value:divide(3600):mod(60):prepend(0)},${value:divide(3600):mod(60)})} A simpler approach would be to use the toDate and Format NEL functions: ${value:toDate('sssss'):format('HH:mm')} I allow 5 's' assuming that max value would be 86,500 seconds (24 hours in a day) and does not matter if value is smaller.   This format also allows you to quickly and easily adjust format for example, maybe you don't want to truncate the remaining seconds and use ":format('HH:mm:ss')" instead. If you found that the provided solution(s) assisted you with your query, please take a moment to login and click Accept as Solution below each response that helped. Thank you, Matt ... View more

@New_User  There is the following resolved jira for the creation of a new putIceberg NiFi processor: https://issues.apache.org/jira/browse/NIFI-10442 Apache has size limits on distributions and it does not appear as though this processor nar was included in the Apache release. You would need to add the nifi-iceberg-processors-nar manually to your NiFi installation for it become available for use. If you found that the provided solution(s) assisted you with your query, please take a moment to login and click Accept as Solution below each response that helped. Thank you, Matt ... View more

@tkchea  NiFi Remote Process Groups (RPG) transfer FlowFiles and not just the FlowFile content. So depending on the amount of metatdata/attributes on the FlowFile. the amount transferred would be larger. The RPG fetches Site-to-Site (S2S) details via a background thread the runs every 30 seconds regardless of existence of FlowFile.  These S2S details fetched will include details on the target NiFi (Number of nodes in target cluster, load on each node, RAW ports if configured, If HTTP is enabled, etc..).  These details are then used to facilitate the transfer of FlowFiles from client (RPG) and target NiFi (with Remote input or output ports).     The actual transfer of FlowFile will either happen over the HTTPS port (used by a lot of other transactions) or via a RAW socket port depending on configuration. Since a FlowFile consists of two parts (FlowFile Metadata and FlowFile Content), there is going to be disk and CPU I/O involved with writing to the flowfile_repository and content_repository.  So you may want to monitor those on both source and destination.  When it comes to the mutual TLS handshake, NiFi is not doing anything special here.  The client certificate presented is used to identify the client and verify authorization to the send to or pull from a remote port. You can also enable ssl handshake debug logging in the nifi bootstrap.conf file. java.arg.ssldebug=-Djavax.net.debug=ssl,handshake Of course you see all SSL handshakes including those when someone access the NiFi UI in the nifi-bootstrap.log file.   But this would allow you to see if you are seeing systematic slow TLS handshakes or only between these two networks.  You could also setup an RPG that sends to a remote input port on the same NiFi server.  The same TLS handshake will happen there as well.  Is it much faster (rules out an RPG issue.)  If it ends up being the network between NiFi servers, you'll need to investigate there perhaps using something like wireshark may help. Another test might involve using a postHTTP or InvokeHTTP to send to a ListenHTTP or HandleHTTPRequest processor on target server (can be setup to be secure or insecure using same keystore and truststore your NiFi's use). If you found that the provided solution(s) assisted you with your query, please take a moment to login and click Accept as Solution below each response that helped. Thank you, Matt ... View more

@Girish007 Did you make sure that the NiFi directories and repository directories are excluded from any virus software scanning?  That is typically the external force that is likely to being making changes to these files. Do you have any other external software or processes scanning or access these directories? Thanks, Matt ... View more