@yuanhao1999  I see that you raised an Apache Jira for this same issue. https://issues.apache.org/jira/browse/NIFI-13340 and that your issue is likely related to: https://issues.apache.org/jira/browse/NIFI-13281 When you delete and re-create import the Process Group from NiFi-Registry, all your components will get new random UUIDs assigned to them.  That effectively eliminates the stuck condition. Where changes being made to process group configuration while FlowFile(s) were still queued in a connection within the Process Group? Please help our community thrive. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more

@inkerinmaa  Out of the box Apache NiFi is configured to be secure.  and Most browser do not support HTTP anymore and force redirect to HTTPS.  NiFi is going to come up in secured if you have the HTTPS port property configured in the nifi.properties file.  So you would need to unset that property for NiFi to start unsecure. Thanks, Matt ... View more

@Alexy  Are you specifically needing to produce so much logging? What loggers do you have added to your logback.xml? How many are set to "INFO" level logging?   If you only want to log exceptions, you could change the "INFO" to "WARN" or "ERROR" to greatly reduce mount of INOF logging being produced. As far as NiFi performance goes, it is all about managing CPU Load average and Disk I/O (Specifically disk I/O of the disks where NiFi's content, flowfile, and provenance repositories are located).  You could make sure your logs are being written a separate disk to elevate that Disk I/) form impacting NiFi's repos disks.  Please help our community thrive. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more

@scoutjohn  I installed an out-of-the-box Apache NiFi 1.26 using single user providers and the NiFi self-signed generated certificates. I was able to send provenance events via the S2SProvenanceReportingTask successfully back to a Remote Input Port on the same NiFi with no issues.  So authorization is not an issue here.  I tested using both HTTP and RAW transport protocols successfully. I also validated that S2S was working by setting up a Remote Process Group to send FlowFiles to a Remote Input port as well.  Here is the dataflow I setup: You can see in the above that i generated some FlowFiles that were sent over S2S to the "Input1" remote port.  You can also see that my "prov" port received provenance events from the S2SProvenanceReportingTask. My S2S setting from nifi.properties file:   # Site to Site properties nifi.remote.input.host=localhost nifi.remote.input.secure=true nifi.remote.input.socket.port=10001 nifi.remote.input.http.enabled=true nifi.remote.input.http.transaction.ttl=30 sec nifi.remote.contents.cache.expiration=30 secs   My Remote Process Group configuration: Switching to "HTTP" transport protocol also worked. S2SProvenanceReportingTask configuration: While all of this worked correctly, sending provenance events via the S2SProvenanceReportingTask back to the same NiFi is not advisable.  It creates an endless loop of provenance events.  For every FlowFile received on the "prov" port another provenance "RECEIVE" event is created which then gets set by the reporting task.  This an infinite loop is created. You would certainly have difficulty related to authentication and authorization sending to another NiFi instance using the out-of-the-box keystore, truststore, and single user providers between two out of the box NiFi deployments.   But for testing purposes this works. Now I see from your configuration you setup:   nifi.remote.input.host=cd8e8c899db6     Makes me wonder if that given hostname is: A SAN entry in the NiFi generated keystore certificate.  You could use keytool command to check.   keytool -v -list -keystore keystore.p12​   That hostname is resolvable and reachable by your NiFi instance.   Try changing that property to "localhost" see if it resolves your issue. Please help our community thrive. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more

@Vikas-Nifi  @ckumar is 100% correct.  Only fields explicitly marked as supporting NiFi Expression Language (NEL) can support a NEL expression "${schedule}". I am however curious about your use case as to why you would even being trying to do this.  From what you shared you are extracting a cron schedule from the json content of some FlowFiles traversing an EvaluateJsonPath processor.  That "schedule" is added on to the NiFi FlowFile as a FlowFile attribute (key=value pair).   This would not make that key=value pair accessible to any other NiFi component unless that FlowFile containing the FlowFile attribute was processed by that other component.   However, in your shared dataflow you do not mention that EvaluateJsonPath connects to your invokeHTTP processor via an inbound dataflow connection (Keep in mind that even if you did do this, it does not change the fact that the run schedule property does not support NEL).   I just wanted to clarify how FlowFile attributes are and can be used. Also keep in mind that the "run schedule" is a scheduler only.  The run schedule set on a processor controls when the NiFi controller will schedule the execution of the processors code.  It does not mean that they the processor will immediately execute at time of scheduling (It may be delayed on execution waiting for an available execution thread from the thread pool).  All scheduled components share a thread pool and NiFi framework will also handle assigning threads to next scheduled component as thread become available.  So the NiFi framework needs to know the scheduling for a component when it is started; otherwise, NiFi would never know when to schedule it to execute.   Unless a component property has an explicit tool tip that tells you it support NEL, then it does not.  For NiFi processor components, you will find that only some processor specific properties within the "PROPERTIES" tab support NEL.  This is not only available through property tooltips, but also in the processors documentation. Examples: Even when NEL is supported there is a scope.  It may support FlowFile attributes, Variable Registry (going away in NiFi 2.x releases), or both.  Thank you,  Matt ... View more

@scoutjohn  The article you are using for reference was written back in 2016 before NiFi was changed to starting secure out of the box.   It is written entirely around that unsecured NiFi example.  You could always unsecure your NiFi and test out S2S capability.  That would atleast allow you to test/evaluate the functionality. When NiFi is secure both authentication and authorization must be handled.  This includes authentication and authorizations for S2S operations.    An out-of-box installation of NiFi utilizes self -generated self-signed certificates to create the keystore and truststore files needed for mutualTLS. It also uses a very basic non production single-user-provider for user authentication and a single-user-authorizer for user/client authorization.  These basic providers make it easy to evaluate NiFi, but are not robust enough to support all features.  Is this what you are using still or have you created your own keystore and truststore files and setup non single user authentication and authorization providers? To be honest, I always setup production ready NiFi instance and clusters that don't use the auto-generated self-signed certificates and or single user providers.  I can't say that I have tried using S2S in such out-of-box environment.  So I can't say that the single-user-authorizer supports those needed authorizations. Above being said, I see you set nifi.remote.input.http.enabled=true, but all that property does is allow http transport protocol which means that means that the NiFi would support transferring FlowFiles over http protocol.  That does not mean unsecured, it could be http or https depending on the destination URL.   The S2S properties in the the NiFi properties need to be modified to support secure S2S by changing nifi.remote.http.secure=true (you did not comment if you made that change or not).  1. Is your S2SProvenanceReportingTask producing any bulletin messages? 2. Are you seeing any not authorized related log lines in the nifi-user.log? 3. What keystore and truststore did you configure in the StandardRestrictedSSLContextService controller service? I'll try to mess around with and out-of-box setup if that is what you are using to see if what you are trying to do is possible in such a non-production ready setup when I have some time. Please help our community thrive. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt     ... View more