[
https://issues.apache.org/jira/browse/MINIFICPP-1494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ferenc Gerlits updated MINIFICPP-1494:
--------------------------------------
Description:
There are some differences between the NiFi and MiNiFi implementations of
InvokeHTTP. I suspect these are not intentional, and we should change MiNiFi
to behave in the same way as NiFi.
# When InvokeHTTP is timer-driven and the Method is GET, then NiFi does not
require an incoming flow file, but MiNiFi does.
# The NiFi version of InvokeHTTP has an output relationship called Original.
This is called Success in MiNiFi; it should probably be renamed to Original.
TODO: any others?
*These changes could break some existing flows; discuss whether this is
acceptable.*
EDIT: in (1), the problem is not really with InvokeHTTP but with
SchedulingAgent::hasWorkToDo():
{noformat}
bool SchedulingAgent::hasWorkToDo(const std::shared_ptr<core::Processor>&
processor) {
if (processor->getTriggerWhenEmpty() || !processor->hasIncomingConnections()
|| processor->isWorkAvailable())
return true;
else
return false;
}{noformat}
InvokeHTTP does not set _triggerWhenEmpty, so {{getTriggerWhenEmpty()}} is
false; *if it has no real incoming connection but there is a Retry self-loop*,
then {{hasIncomingConnections()}} is true, and {{isWorkAvailable()}} is false
unless there are flow files waiting to be retried. As a result,
{{InvokeHTTP::onTrigger()}} will never get called.
was:
There are some differences between the NiFi and MiNiFi implementations of
InvokeHTTP. I suspect these are not intentional, and we should change MiNiFi
to behave in the same way as NiFi.
# When InvokeHTTP is timer-driven and the Method is GET, then NiFi does not
require an incoming flow file, but MiNiFi does.
# The NiFi version of InvokeHTTP has an output relationship called Original.
This is called Success in MiNiFi; it should probably be renamed to Original.
TODO: any others?
*These changes could break some existing flows; discuss whether this is
acceptable.*
> InvokeHTTP should behave in the same way as NiFi
> ------------------------------------------------
>
> Key: MINIFICPP-1494
> URL: https://issues.apache.org/jira/browse/MINIFICPP-1494
> Project: Apache NiFi MiNiFi C++
> Issue Type: Improvement
> Reporter: Ferenc Gerlits
> Assignee: Gabor Gyimesi
> Priority: Minor
>
> There are some differences between the NiFi and MiNiFi implementations of
> InvokeHTTP. I suspect these are not intentional, and we should change MiNiFi
> to behave in the same way as NiFi.
> # When InvokeHTTP is timer-driven and the Method is GET, then NiFi does not
> require an incoming flow file, but MiNiFi does.
> # The NiFi version of InvokeHTTP has an output relationship called Original.
> This is called Success in MiNiFi; it should probably be renamed to Original.
> TODO: any others?
> *These changes could break some existing flows; discuss whether this is
> acceptable.*
> EDIT: in (1), the problem is not really with InvokeHTTP but with
> SchedulingAgent::hasWorkToDo():
> {noformat}
> bool SchedulingAgent::hasWorkToDo(const std::shared_ptr<core::Processor>&
> processor) {
> if (processor->getTriggerWhenEmpty() ||
> !processor->hasIncomingConnections() || processor->isWorkAvailable())
> return true;
> else
> return false;
> }{noformat}
> InvokeHTTP does not set _triggerWhenEmpty, so {{getTriggerWhenEmpty()}} is
> false; *if it has no real incoming connection but there is a Retry
> self-loop*, then {{hasIncomingConnections()}} is true, and
> {{isWorkAvailable()}} is false unless there are flow files waiting to be
> retried. As a result, {{InvokeHTTP::onTrigger()}} will never get called.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
