@hegdemahendra  The ConsumeAzureEventHub processor utilizes the AzureSDK library. The AzureSDK manages an internal thread pool for consuming events outside of the control of the NiFi processor.  When the processor is started the single concurrent task thread is used to give a handle to the AzureSDK Session Factory.  At that point all thread control pertaining to the consumption of events is outside the bounds of the NiFi framework.  There are unfortunate side effects caused by using the AzureSDK in this processor.  Since thread handling is moved out of the NiFi framework control, backpressure on the outbound connection(s) of this processor are not going to be honored.  NiFi Framework handles backpressure as a soft limit and once the threshold on the connection is met or exceeded, the framework stops scheduling the source component. Since the ConsumeAzureEventHub processor on startup only gets "scheduled" once (hands off thread to AzureSDK to handle thread pool and consumption, the processor never needs to be scheduled again (always on). Only stopping the processor will stop the underlying AzureSDK from consuming more events.  Risk here is that if a downstream issue happens, the connection(s) outbound from the ConsumeAzureEventHub processor will continue to grow until you run out of disk space on the FlowFile or content repository disks. The following Jira covers this limitation: https://issues.apache.org/jira/browse/NIFI-10353 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

@hegdemahendra  There currently are no NiFi processors for ingesting from Delta Lake.  There is an existing Apache Jira for creating such list/fetch processors for Delta Lake, but it is still open and does not look to be actively being worked on: https://issues.apache.org/jira/browse/NIFI-7093 I am not aware of any open source 3rd party options here as well. 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

@SandyClouds  What i am saying is that rest-api call response you got via command line is probably not the exact same request made by NiFi.   What that response json tells you is that the user that made the request only has READ to all three buckets. You did not share the complete rest-api call you made, so I am guessing you did not pass any user authentication token or clientAuth certificate in yoru rest-api request and this that request was treated as bing made by an anonymous user.  Since your bucket(s) have the "make publicly visible" checked, anonymous user will have only READ access to the buckets. In NiFi you are trying to start version control on a Process group.  That means that the NiFi node certificate needs to be authorized on all buckets and authorized to proxy the NiFi authenticated user (who also needs to have read, write on the specific bucket to start version control.  If the response received back to NiFi during the request is that nodes or user on has READ, then no buckets would be shown in that UI since the action that UI is performing would be a WRITE.   You should use the "developer tools" in your web browser to capture the actual full request  being made by NiFi when you try to start version control on a process group.  Most developer tolls even give you and option to "copy as curl" which you can then just paste in a cmd window and execute manually yourself outside of NiFi to see the same response NiFi is getting. My guess here is that you are having a TLS handshake issue resulting in yoru requests to NiFi-Registry being anonymous requests.   The NiFi logs are not going to show you details on what authorization was on the NiFi-Registry side (you'll need to check the nifi-registry-app.log for that).  All the NiFi log you shared shows is that your "new_admin" was authorized to execute the NiFi rest-api endpoint.  This triggering the connection attempt with NiFi-Registry which also appeared successful (likely as anonymous). If you look at the verbose output for the NiFi keystore, NiFi truststore, NiFi-Registry keystore, and NiFi-Registry truststore, you'll be able to determine if a mutual TLS exchange would even be possible between the two services using the keystore and truststores you have in place.  These versbose outputs which you can get using the keytool command will also show you the EKUs and SANs present on your certificates. <path to JDK>/keytool -v -list -keystore <keystore or truststore file> When prompted for password, you can just hit enter without providing password. The screenshots you shared showing the authorizations configured in NiFi-Registry are sufficient.  I was simply pointing out that you gave too much authorization to your NiFi node in the global policy section.   This is why i am leaning more to a TLS handshake issue resulting in an anonymous user authentication rather then an authorization issue.  You'll also want to inspect your nifi-registry-app.log for the authorization request coming from NiFi to see if is authorizing "anonymous" or some other string.  Perhaps you have some identity mapping pattern configured on NiFi-Registry side that is trimming out the CN  from your certificate DNs?  In that case you could also see this behavior because your NiFi-Registry would be looking up authorization on different identity string (instead of "CN=new_admin, OU=Nifi, i maybe looking for just "new_admin").  NiFi and NiFi-Registry authorizations are exact string matches (case sensitive); otherwise, treated as different users. 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

@hackerway  I would not recommend using the embedded zookeeper as zookeeper quorum must be maintained in order for yoru NiFi cluster to remain stable.  Losing a NiFi node also takes down the embedded zookeeper running with that NiFi.   While I would recommend keeping your zookeeper quorum installed on its own servers separate from the NiFi service (NiFi can be a resource intensive application depending on dataflow designs and data volumes), you may be able to run yoru external ZK servers and NiFi servers on the same hardware. Sounds like you have established dataflows and resource usage is low on your servers, but that may change if you add to your existing dataflows, add new dataflows, and/or there is a change in data size/volume.  You'll want to be looking at all resource consumption over time before making a decision here: - CPU Load (core load average as well as peaks) - Memory utilization on yoru servers to make sure there is sufficient memory to support both ZK and NiFi. - Disk I/O NiFi can have a lot of disk I/O with it local repositories (content, flowfile, and provenance). So if Disk I/O is high adding ZK to the same host could impact throughput of your NiFi 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

@hegdemahendra  SASL_SSL is Simple Authentication and Security Layer over a TLS encrypted connection. A TLS encrypted connection is going to require that the server (Kafka) has a server certificate.  There are two types of TLS connection (1-way and mutual). Without going very deep in to this process, i'll keep it very high level).  In a 1-way TLS connection only the server (Kafka in your case) presents information in the TLS exchange.  The client (NiFi Kafka processor in your case) does not present information back to the server. The client will verify if they trust the information provided from the server.  The servers serverAuth certificate will be signed by some certificate authority and the client will verify if that signing authority's trust chain is trusted and if if it is will accept the Server's information allowing the TLS connection to proceed.   Now it is possible for the client to choose to trust the server (unsecure) without verifying the trust chain.  This is unsafe, so NiFi and its components (Processors, controller services, reporting tasks, RPG, etc) will not allow that.  So the processor will require that a SSL Context Service is created.  You'll need to configure that SSL Context Service with a SSL truststore which contains the complete trust chain for the Kafka signed certificate.  No need for configuring the keystore properties. In a Mutual TLS connection, both sides (server and Client) will present information to each other to identify themselves in order to establish the encrypted TLS connection.  In a mutual TLS exchange, the Client must be capable via its truststore to trust the compete trust chain for the server's certificate issuer.  And the Server must be capable via its truststore to trust the complete trust chain for the clients certificate issuer. Since you are authenticating via SASL via username and password, you'll only need 1-way TLS encrypted connection. You can manually create a truststore.jks to use for this.  You should be able to use openssl to get the public keys needed to do this from yoru kafka target: openssl s_client -connect <kafka hostname>:<kafka port> -showcerts The output from this should contain all the public keys in the trust chain. Each certificate will look something like this: -----BEGIN CERTIFICATE----- MIIFYjCCBE......yilrbCgj8= -----END CERTIFICATE----- The "-----BEGIN CERTIFICATE-----" and "-----END CERTIFICATE-----" are part of the certificate. You can save each certificate as a "key<num>.pem" file and the import them in to your truststore you when then use in your SSLContextService. 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