@Gutao  When interacting with the NiFi rest-api, I'd recommend creating a client certificate to use in your automation.  A secured NiFi will always WANT a client certificate and will only try another configured auth method if a client certificate is not provide in the TLS exchange.  Using a certificate for your rest-api automation removes the need for obtaining a token completely.  You simply pass your client certificate with every rest-api call.   Another advantage here over auth is token expiration. With no token involved with certificate based auth, your certificate will continuously work until it expires (typical default is 1 or 2 years).  You'll need to setup authorization policies for your certificate user (Certificate DN used as user identity) for the various endpoints you are trying to interact with through the rest-api. 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

@mbraunerde Based on what you shared , you are not configured to interact/use your AzureAD at all. Your nifi.properties is configured to use the out-of-the-box "single-user-provider":   nifi.security.user.login.identity.provider=single-user-provider   This login provider generates a single local user with the specific username and password configured in the provider's configuration within the login-identity-providers.xml The only authorizer that supports the single-user-provider is the single-user-authorizer which simply gives your single configured user complete access to everything in your NiFi.  The other authorizer in your authorizers.xml is not being used at all.  These single user authentication and authorization providers also are not support in a NiFi cluster setup.  Their intent when created was simply to make it real easy for user just starting to experiment with NiFi to have a secured setup, so that their NiFi UI was not exposed to the world over http. The first thing i'd recommend is setting up your NiFi in a more production ready configuration using certificate you generate or generate through a certificate authority.  Then switch to a different authentication and authorization providers.  For example the ldap- provider for login which can be configured to authenticate users via LDAP/AD.   Then pair that with a managed authorizer.  This production ready authentication and authorization setup will then give you the ability to support authentication for multiple users and give you ability to set user specific authorizations that control what each user is allowed to access and interact with.  As far as interfacing with your NiFi via the NiFi-API, the recommend method would be to create a clientAuth certificate for the interaction.  A secured NiFi (HTTPS) will support authentication via a mutualTLS handshake (only if not using single user) always.  Meaning it will WANT a client certificate when interacting with the URL or via the rest-api.  If the a client certificate is not presented, NiFi will attempt next configured authentication method.  While you can use other authentication methods to interact with the rest-api (like ldap-provider), it is more difficult to manage since you would first need to interact with the login rest-api endpoint to get a client token and store that token so it can be passed in every additional rest-api call you make.  That token does expire which means you would need to fetch a new token periodically.  With a clientTLS certificate through a mutualTLS based authentication, you simply include that client certificate in every rest-api call (no need to get a token). Client certificate can have a configurable expiration (typically 1 or 2 years by default). 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

@MarcusBrandao  As @cotopaul mentioned, providing the full error and any stack trace that may follow might help in your query.  You may also want to to look for any other WARN or ERROR log output generated around the time of attempting the version control your process group.  I'd  look for anything related to Out of Memory (OOM) or too many open files.  Also look at the JVM your NiFi is using. How often and how long are your garbage collection events? 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 If you don't care about the specific formatting of the FlowFiles content, you could use the ReplaceText processor to append test to the end of the existing content.  I am assuming that you are manually investigating the failure later and will simply remove the appended putdatabaserecord.error text during the evaluation. 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

@srv1009  Are you sure you are removing or replacing a flow.xml.gz.  Apache NiFi 1.19 uses the flow.json.gz.  The flow.json.gz is auto generated from the flow.xml.gz if and only if the flow.json.gz does not already exist at startup. As far as flow changes in your production environment goes... All the following are flow config changes: 1. Moving a component 2. Changing state of a component (start, stop, enable, disable) 3. Importing a flow from the nifi-registry or changing the version of a version controlled flow. So you are saying none of the above are happening ever in prod (seems unlikely)? You mentioned that you have "checkpointing" enabled.  The only "checkpointing" that NiFi does is NOT related the flow.ml.gz or the flow.json.gz.  It has to do with checkpointing the flowfile_repository which contains metadata about NiFi FlowFiles queued within connection in your datflows on the canvas. The flow.json.gz is only file being used on startup once it has been generated.  Are you having disk space issues? Archive can be enabled for the flow.json.gz as part of the following properties:   Archive of flow.json.gz only happens when a configuration change is made on the NiFi canvas or via some change via NiFi rest-api interaction resulting in changes to datafow(s).  Archive when enabled does not randomly generate archive copies of the flow.json.gz.  Only happens with each change.  So if you are seeing an archive of teh flow.josn.gz generated every few minutes in the configured archive.dir?  If so, then changes to your dataflow are happening. Are you sure that the SIGTERM is executing a clean shutdown of the NiFi process (./nifi.sh stop) or is it just killing the NiFi process id?  If a graceful shutdown is happening you would see that in the nifi-bootstrap.log. The Graceful shutdown period is configurable by this property:   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

@srv1009  If NiFi is "restarting" itself, that means NiFi did not receive a graceful shutdown request. When NiFi is launched, the bootstrap process is started, that bootstrap process then starts the NiFi core as a child process and monitors for the child process pid.  If that pid disappears or the NiFi core is not responding, the bootstrap process will assume the core has died and will restart it. Typically in such scenarios, this is the result of the OS killing off the NiFi core process pid.  In linux the OOM Killer will do this when system memory gets too low and it sees that child process as the largest consumer of system memory.  The latest version of NiFi use a flow.json.gz to persist the dataflow.  If you are still using a flow.xml.gz, what version of NiFi are you running?   Regardless the NiFi flow is unpacked on startup and loaded into NiFi heap memory.  When a change occurs on the canvas, the current flow.json.gz/flow.xml.gz is archived and a new one is created.  To have corruption in the newly written flow.josn.gz/flow.xml.gz, that means the core NiFi process was killed while that was being written out to disk.  Or like @cotopaul you have some disk corruption going on. With a graceful shutdown of the NiFi service, there is a 10 second grace period for current threads to complete before the core is killed.  If you are having some disk issues, high disk latency, or disk space issues, maybe the writing of your flow.xml.gz is taking a lot longer and process is being killed before that completes, but that seems slim as multiple things would need to happen in succession (Change on canvas at almost exact time you initiate a graceful shutdown).  You could increase the graceful shutdown in the nifi.properties, but i doubt that is what is impacting you here.   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