@hegdemahendra  This could be and IOPS issue possibly, but it could also be a concurrency issue with threads. How large is your Timer Driven thread pool?  This is the pool of threads from which the scheduled components can use.  If it is set to 10 and and all are currently in use by components, the HandleHTTPRequest processor , while scheduled, will be waiting for a free thread from that pool before it can execute.  Adjusting the "Max Timer Driven Thread pool" requires careful consideration of average CPU load average across on every node in your NiFi cluster since same value is applied to each node separately.  General starting pool size should be 2 to 4 times the number of cores on a single node.  Form there you monitor CPU load average across all nodes and use the one with the highest CPU load average to determine if you can add more threads to that pool.  If you have a single node that is always has a much higher CPU load average, you should take a closer look at that server.  Does it have other service running on it tat are not running on other nodes?  Does it unproportionately consistently have more FlowFiles then any other node (This typically is a result of dataflow design and not handling FlowFile load balancing redistribution optimally.)? How many concurrent tasks on your HandleHttpRequest processor.  The concurrent tasks are responsible for obtaining threads (1 per concurrent task if available) to read data from the Container queue and create the FlowFiles.  Perhaps the request come in so fast that there are not enough available threads to keep the container queue from filling and thus blocking new requests. Assuming your CPU load average is not too high, increase your Max Timer Driven Thread pool and the number fo concurrent tasks on your HandleHttpRequest processor to see if that resolves your issue.  But keep in mind that even if this helps with processor getting more threads, if the disk I/O can't keep up then you will still have same issue. As far as having all your NiFi repos on same disk, this is not a recommended practice.  Typical setup would have the content_repository on its own disk (content repo can fill disk to 100% which does not cause issue other then not being able to write new content until disk usage drops), The provenance_repository on its own disk (size of this disk depends on amount of provenance history you want to retain and size fo your dataflows along with volume of FlowFiles, but its disk usage is controllable. Recommend separate disk due to disk I/O), and put the database_repository (very small in terms of disk usage) and flowfile_repository (relatively small unless you allow a very large number fo FlowFiles to queue in your dataflows.  FlowFile_repos only hold metadata/attributes about your queued FlowFIles, but can also be I/O intensive on disk) together on a third disk. If you found this response assisted with your query, please take a moment to login and click on "Accept as Solution" below this post. Thank you, Matt ... View more

@AbhishekSingh  1. @araujo response is 100% correct. 2. Just to add to @araujo respsonse here...  NiFi-Registry has nothing to do with controlling what user can and can't do on the NiFi canvas.  It simply allows users if it is installed to version control process groups.  Even once a NiFi process group has been version controlled, authorized users in NiFi can still make changes to dataflows (even those that re version controlled).  One they do make a change to a version controlled Process Group, that process group will indicate that a local change has been made and the authorized user will have the option to commit that local change as a new version of the dataflow.  Controlling what users can do with dataflows is handled via authorization policies which NiFi handled very granularly.  Authenticated users can be restricted to only specific Process Groups. Your NiFi admin user  can setup NiFi authorization for other user per Process Group if they want by selecting the Process Group and clicking on the "key" icon in the "operate panel" on the left side of the NiFi canvas.   If you found any of the responses provided assisted with your query, please take a moment to login and click on "Accept as Solution" below each of those posts. Thank you, Matt ... View more

@PradNiFi1236    There are numerous steps in this process.  So lets start with some basics on Site-To-Site (S2S).  The S2SBulletinReportingTask works much like the NiFi Remote Process Group (RPG).  When configured with a Destination URL and enabled a background thread will run independently on an interval to fetch S2S details from the destination URL.  If the destination url is a node in a NiFi cluster, the returned S2S details will include the hostnames of all the nodes in the cluster, whether cluster nodes are configured to support RAW and/or HTTP transport protocols, the configured RAW port for each node, node load average, etc... Configuring just one destination URL from the target cluster does not change this behavior.  Configuring a comma separate list of nodes from the same destination cluster affords you HA.  If S2S details can't be retrieved from node URL 1, it then tries second URL, and so forth. Also keep in mind it does not matter what node URL of a NiFi cluster you are accessing, any component (processor, reporting task, controller service, etc) added to the canvas is replicated to all nodes in the NiFi cluster.   So when you enable this S2SBulletinReporting task, all nodes are going to try to fetch S2S details.  Each node in a NIFi cluster has all the same components and executes all the same components (with exception of processors that can be scheduled to execute on primary node only). This means that all node will be trying to send generated bulletins to your cluster nodes. So by what you shared, it looks like the background thread that fetches those S2S details is failing due to timeout.  This could be for any number of reasons.  Your configured keystore in the sslContextService does not contain a single PrivateKeyEntry that can be trusted by the truststore configured in the nifi.properties file on all 3 of your destination nodes.  The PrivateKeyEntry presented by the 3 NiFi nodes to the controller service is not trusted by what exists in the truststore configured in your SSLConTextService.  keystore used in sslContextService does not have a clientAuth PrivtaeKeyEntry in it. nifi.remote.input.secure is not set to true. nifi.remote.input.http.enabled not set to true.   There are several authorization policies in play here as well, but I don't think you have even gotten that far yet. Retrieve site-to-site details  <-- The privateKeyEntry from the keystore configured in the sslContextService will need to be authorized to retrieve these S2S details.  The keystore used in each of your 3 NiFi node's sslContext service may have unique DNs for their PrivateKeyEntry.  So all three of those unique keys would need to be authorized Receive data via site-to-site  <-- The privateKeyEntry from the keystore configured in the sslContextService will need to be authorized to retrieve these S2S details.  The keystore used in each of your 3 NiFi node's sslContext service may have unique DNs for their PrivateKeyEntry.  So all three of those unique keys would need to be authorized.  This allows the S2SBulletinReporting task to see this bulletinmonitoring remote input port as an option to send bulletins to. But if you were getting past authentication and failing on authorization, your exception would be different.  Instead of timeouts, you would be seeing not authorized exceptions. If you found this response assisted with your query, please take a moment to login and click on "Accept as Solution" below this post. Thank you, Matt ... View more

@Alevc  Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target The above exception you are encountering with TLS is caused by a lack of a complete trust chain in the mutual TLS handshake. On each side (server and client) of your TLS connection, you will have a keystore containing a PrivateKey entry (Will support and extended key usage (EKU) of clientAuth, serverAuth, or both) that either your client or server will use to identify itself.   That PrivateKey entry will have an owner and issuer DN associated with it.   The issuer is the signer for the owner.  Each side will also have a truststore (just another keystore by a different name containing a bunch of TrustedCertEntry(s)) that would need to contain the trustedCertEntry for the issuer/signer of your PrivateKeyEntry.  It is also very common that the issuer/signer trustedCertEntry has an owner DN and Issuer DN that do not match. This means that that issuer was just an intermediate Certificate Authority (CA) and was issued/signed by another CA.  As such the truststore would need to also contain the TrustedCertEntry for that next level issuer CA.  This continues until you reach the root CA trustedCertEntry where the owner and issuer have the same DN.  This is known as the rootCA for your PriavteKeyEntry.   Having all the intermediate CA(s) and the root CA, means you have the complete trust chain in your truststore.  This process applies in both directions in the mutual TSL handshake.  Meaning your clientAuth certificate presented by your Kafka Consumer must have its complete trust chain in the Kafka servers truststore.  And the ServerAuth certificate presented by your server must have its complete trust chain present in the truststore used by your client Kafka consumer.   Note: I am over simplifying this mutual TLS handshake (private keys themselves are never shared and there is more in the server and client hello exchanges in the TLS handshake), but intent is to focus at a high level on what your issue is caused by specifically. So to get past your issue, you need to make sure the truststore used by your client and server side contain all the CAs trust chain trustedCertEntries. If you found this response assisted with your query, please take a moment to login and click on "Accept as Solution" below this post. Thank you, Matt ... View more

@rafy  Once you have created the certificates for your other two users as @DigitalPlumber suggested, you would need to connect to your NiFi as the admin user you setup during initial securing of your NiFi and these two new users via the NiFi global menu (upper right corner) --> Users.   Then you would need to authorize those new user identities against any policies needed for them to perform the actions you want them to be allowed.  https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#config-users-access-policies   Hope this helps, Matt ... View more

@Hashem1980  Neither the ConsumeIMAP or ConsumePOP3 NiFi processors support Oauth2 for authentication. NiFi does have an StandardOauth2AccessTokenProvider controller service.  I would recommend opening an Apache NiFi Jira asking to have Oauth2 via this existing controller service integrated in to these processors.  As an open source project contribution are always welcome. If you found this response assisted with your query, please take a moment to login and click on "Accept as Solution" below this post. Thank you, Matt ... View more