Support Questions
Find answers, ask questions, and share your expertise
Announcements
Alert: Welcome to the Unified Cloudera Community. Former HCC members be sure to read and learn how to activate your account here.

Does NiFi MonitorActivity seem flawed without the potential for start-up delay or trigger to life property?

Highlighted

Does NiFi MonitorActivity seem flawed without the potential for start-up delay or trigger to life property?

New Contributor

I'm a little confused by the MonitorActivity in Hortonworks/NiFi data flows. The essence of the processor makes perfect sense, but for a complex data flow that spans many thousands of files the processor seems like it's missing the option to delay or trigger to the time it actually starts to monitor.

If I bring down my workflow and restart it then I would like to be able to delay when the monitor actually begins to watch for inactivity. If I have 15-20 minutes of other processing to occur before I even get to the group that needs monitoring then I am guaranteed to get at least one file trigger for inactivity. That seems logical, but at the same time, a little limited. If I could trigger the monitor on the first inbound flowFile on the monitored process then all would fall into how I would expect the processor to behave:

InvokeHttp (on first flowfile trigger the monitor) -> MonitorActivity (starts to monitor on first flowfile in InvokeHttp) -> Next Processor is triggered upon the InvokeHttp being inactive for 2 minutes.

Thoughts, and/or ideas to get around this limitation?

Don't have an account?
Coming from Hortonworks? Activate your account here