/nifi-api/flow/metrics/prometheus   ... View more

@nifier  I would not expect much difference between making the stop request via the NiFi UI or via a rest-api call.  Even when you make a request to stop components via the NiFi UI, the UI may quickly show the "stopped" icon on the component, but any active threads are not killed in that process.  In fact the processor is considered "stopping" until all its active threads complete however long that takes.  While still in the state of stopping, you can not modify those components.   A component is considered stopping if its "activeThreadCount" is not 0. when you are executing your rest-api script without the delay, what exception are you encountering? This one? unable to fulfill this request due to: Cannot start component with <component id> because it is currently stopping  Above means you have active threads. Perhaps you can build a wait loop around above response until the active threads complete.  Or you can capture that component id and execute a terminate threads command on it. ../nifi-api/processors/<component id>/threads -X DELETE Terminating threads will not cause data loss.  NiFi is not killing any threads in this process, only way to kill threads is via a NiFi restart.  Terminating threads on component just shifts the thread to dev null and unhooks it from the FlowFile(s) it is associated with in the inbound connection. When the processor is restarted, the FlowFile(s) will be reprocessed by the component.  Should the "terminated" thread complete execution its logging and output just goes to dev null and results are not written back to a FlowFile, but depending on processor it could end up in duplicate data on a destination system if the tread is sending data out of NiFi since NiFi will reprocess the FlowFile originally associated with that terminated thread next time processor is started. The other option is to get the status of components for the process group you stopped and parse the json for any "activeThreadCount" were count is not 0 and wait 1 sec and make request again and then repeat this loop until all are 0 before making your next rest-api call. Please help our community grow. 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

@MattWho Thank you for the information. ... View more

@Shelton We just followed Steps 1,3 4 and 5 to generate the automated report to Elasticsearch. It was pretty straight forward. Only things is we had to do was enable firewall in our Docker container and update Input Port's Access Policies. Thanks   ... View more

Thanks @MattWho for your response. ... View more

@nifier  I am not seeing the same behavior as you have reported which make me think your extracted.path is not not really 0 bytes. I suggest adding another dynamic property to your update Attribute processor to output the calculated length to verify. Here is what i see after my UpdateAttribute processor (newdir is set using your shared NiFi Expression Language (NEL) statement). So I created  extracted.path with a single white space and then see what you describe, but that whitespace is a byte, so expected output: If it turns out your problem is because you have white space in the Extracted.path attribute, you could modify your NEL statement as follows: ${extracted.path:trim():length():gt(0):ifElse(${extracted.path:append('/'):append(${filename})},${filename})} You use the trim() NEL function to remove leading or trialing whitespace from the extracted.path before calculating length.  This includes trimming of a line return. So in below you will see desired output even though extracted.path length is not 0 because I trimmed white space or line return. Please help our community grow. 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

Thanks @MattWho for your response. ... View more