[ 
https://issues.apache.org/jira/browse/NIFI-583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14576387#comment-14576387
 ] 

Aldrin Piri commented on NIFI-583:
----------------------------------

Patch submitted.

I feel like there's some slight difference in functionality between the test 
runner and the actual framework based on the error reported through how the 
file was handled.  The issue seemed to be based around using the new flow file 
as the source input (and zero bytes).  This was not an error in the testing 
framework, but feels like it perhaps should be.  I think the error is 
complaining that there is duplicative use of that particular flow file in 
different callbacks (or in this case, the same call back but in read and write 
capacities).

Anyone have some more pointed thoughts?

> Provide ExecuteStreamCommand option of streaming contents over STDIN of an 
> incoming flowfile
> --------------------------------------------------------------------------------------------
>
>                 Key: NIFI-583
>                 URL: https://issues.apache.org/jira/browse/NIFI-583
>             Project: Apache NiFi
>          Issue Type: Improvement
>    Affects Versions: 0.1.0
>            Reporter: Ricky Saltzer
>            Assignee: Aldrin Piri
>             Fix For: 0.2.0
>
>         Attachments: 
> 0001-NIFI-583-Adjusting-the-callback-to-be-aware-of-wheth.patch, 
> NIFI-583.1.patch, NIFI-583.2.patch
>
>
> In some cases it would be really nice to allow a FlowFile to trigger an OS 
> action. For instance, after a daily dump of data is written to an Impala 
> table in HDFS, I would like to execute a refresh on the table via the shell. 
> As it stands, the ExecuteProcess processor will allow a FlowFile in a 
> connection to trigger execution, but unless your connection has an expiration 
> set, the FlowFile will stay there indefinitely. The main issue here is that 
> it will continue to re-execute your ExecuteProcess processor over and over. 
> As far as I know, there's only two clear ways around this. (1) - you can use 
> the ExecuteStreamCommand, instead, but *only* if that command can properly 
> handle STDIN. (2) - you can set your ExecuteProcess processor to execute on a 
> schedule (e.g. 1 per minute) and expire the FlowFile before it can re-execute 
> (e.g. 10 seconds). 
> It would be useful if the ExecuteProcess processor consumed the FlowFile, and 
> passed it through a "passthrough" relationship of some kind. A second option 
> would be to make it configurable (false by default) to drop the FlowFile, or 
> to pass it through a second relationship, that way it doesn't break anyone's 
> current pipelines. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to