[
https://issues.apache.org/jira/browse/NIFI-4200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16093414#comment-16093414
]
Pierre Villard commented on NIFI-4200:
--------------------------------------
bq. Why would that processor not be running already? Can you describe this case
further?
Don't have anything specific in mind. But I recall someone that would like to
start ListHDFS only when certain conditions are met to ensure that all the
files are listed at the same time. But the processor does not accept incoming
relationship so it's not really possible to have this behavior. Again, this is
more a batch approach and not really NiFi-thingy but that's something people
could need (at the moment this is solved by calling a script doing the REST API
call). And I also admit that this can now be solved with Wait/Notify: something
like ListHDFS -> Wait -> etc on one hand, and Notify on the other hand. But
some processors do not have this pattern available.
bq. Having an external thing call it then stop it real fast likely wont be
enough as the idea of a single run could differ between processors.
If the processor to start once is configured with "Run Schedule" on, let's say,
5 sec. And the ControlNiFi is configured with "1 sec", then START/STOP would
trigger the processor only once, right? But I agree this depends of what is
doing the processor and we could have different definitions around "once".
bq. This is a bug in those processors and they should be fixed. Processors
should not assume that the things they depend on are static and rely on
application lifecycle to refresh/stay up to date. They should be coded for
continuous operation.
Agree
Another possible use case is to combine ControlNiFi with the
SiteToSiteBulletinReportingTask to proactively stop a processor in case
something wrong is happening. This is also something that is kinda of already
covered by the framework: you can use the failure relationship in combination
with back pressure. Or use the yield duration with a large value.
Generally speaking, I think this is something that could be used in batch
scenarios and that's why I said this is not in the "NiFi way of thinking". I'm
sure there are other scenarios and I also admit there are ways of doing the job
with what we have already (Script, HTTP processors). But this would probably be
easier to use.
> Consider a ControlNiFi processor
> --------------------------------
>
> Key: NIFI-4200
> URL: https://issues.apache.org/jira/browse/NIFI-4200
> Project: Apache NiFi
> Issue Type: New Feature
> Components: Extensions
> Reporter: Pierre Villard
> Assignee: Pierre Villard
>
> We frequently see on the mailing list the need to start/stop a processor
> based on incoming flow files. At the moment, that's something that can be
> scripted or that can be done using multiple InvokeHttp processors but it
> requires a bit of work.
> Even though it is not really in the "NiFi way of thinking", it would be
> interesting to have a processor with the following parameters:
> - NiFi REST API URL
> - Username
> - Password
> - Processor UUID (with expression language)
> - Action to perform (START, STOP, START/STOP, STOP/START)
> - Sleep duration (between the START and STOP calls when action is START/STOP,
> or STOP/START)
> That would be helpful in use cases like:
> - start a workflow based on another workflow
> - start a processor not accepting incoming relationship based on a flow file
> - restart a processor to "refresh" its configuration when the processor
> relies on configuration files that could be changed
> - have a "start once" behavior
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
