Support Questions

Find answers, ask questions, and share your expertise

NiFi API delay

avatar
Rising Star

Hi Team,

we are using NiFi API to disable and enable all the Processors within the Processor Group. If we do it from NiFi UI it happens immediately but from API its takes 10-15 Seconds to take effect.

Which is causing issue with the next API calls, currently we have used a delay of 15 sec before making next call.

But is there a better way to handle this issue ?

1 REPLY 1

avatar
Master Mentor

@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