nifi-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Koji Kawamura <ijokaruma...@gmail.com>
Subject Re: Capturing stdout *and* stderr of command executed by ExecuteStreamCommandProcessor
Date Wed, 14 Dec 2016 01:28:44 GMT
Hello A.B.

I wrote a simple Java class which produces OOM error, and tested how
ExecuteStreamCommand works.

In the case that after the Java program writes some output, then
encounters OOM, it sends an outgoing flow file to "output stream"
containing data produced until the OOM.

The OOM error message can be seen at the "execution.error" attribute
of the outgoing flow file. Also, "execution.status" attribute is set
as "1" (none zero) indicating the command failed.

If you'd like to split subsequent flow based on whether the Java
program succeeded, then adding RouteOnAttribute after
ExecuteStreamCommand.
Add 'success' route with NiFi expression
"${execution.status:equals('0')}" can route flow files.

I put these experiment result as a Gist:
https://gist.github.com/ijokarumawak/0476ca8693058c1909a5842bab903fa3

Hope this helps.
Please let us know if you're seeing different result, there may be a
corner case.

Thanks,
Koji

On Tue, Dec 13, 2016 at 4:14 PM, A.B. Srinivasan
<ab.srinivasan@gmail.com> wrote:
> Hello all,
>
> I have a Java program being invoked within a ExecuteStreamCommand processor.
> Prior to the invocation of the ExecuteStreamCommand, I set up the 'filename'
> property containing the output file into which the ExecuteStreamCommand
> processor directs its output stream.
>
> This works pretty well to capture logger messages output by the Java
> program. However, on the rare occasion when the Java program dies with
> something like an OutOfMemory error, the message is lost and I have no info
> on why the program failed.
> Additionally, if the Java program dies fairly early in its launch before the
> loggers are set up, ExecuteStreamCommand does not even break out and return
> an error.
> In both of these situations, I have to run the program standalone outside of
> the ExecuteStreamCommand to see the errors.
>
> What configuration options do I have for the ExecuteStreamCommand processor
> / its output stream to both capture *all* output directed to stdout and
> stderr and reliably be able to break out and return if the Java program has
> failed to launch?
>
> Thanks,
> A.B.

Mime
View raw message