You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@nifi.apache.org by "ASF GitHub Bot (JIRA)" <ji...@apache.org> on 2018/05/11 21:57:00 UTC

[jira] [Commented] (NIFI-5024) Deadlock in ExecuteStreamCommand processor

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

ASF GitHub Bot commented on NIFI-5024:
--------------------------------------

Github user MikeThomsen commented on a diff in the pull request:

    https://github.com/apache/nifi/pull/2594#discussion_r187742376
  
    --- Diff: nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/ExecuteStreamCommand.java ---
    @@ -351,6 +350,16 @@ public void onTrigger(ProcessContext context, final ProcessSession session) thro
             builder.directory(dir);
             builder.redirectInput(Redirect.PIPE);
             builder.redirectOutput(Redirect.PIPE);
    +        final File errorOut;
    +        try {
    +            errorOut = File.createTempFile("out", null);
    +            errorOut.deleteOnExit();
    --- End diff --
    
    I would like to see this deleted after every iteration of the processor because it could a very long time brefore deleteOnExit gets executed.


> Deadlock in ExecuteStreamCommand processor
> ------------------------------------------
>
>                 Key: NIFI-5024
>                 URL: https://issues.apache.org/jira/browse/NIFI-5024
>             Project: Apache NiFi
>          Issue Type: Bug
>    Affects Versions: 1.3.0
>            Reporter: Nicolas Sanglard
>            Priority: Minor
>         Attachments: Screen Shot 2018-03-28 at 15.34.36.png, Screen Shot 2018-03-28 at 15.36.02.png
>
>
> Whenever a process is producing too much output on stderr, the current implementation will run into a deadlock between the JVM and the unix process started by the ExecuteStreamCommand.
> This is a known issue that is fully described here: [http://java-monitor.com/forum/showthread.php?t=4067]
> In short:
>  * If the process produces too much stderr that is not consumed by ExecuteStreamCommand, it will block until data is read.
>  * The current processor implementation is reading from stderr only after having called process.waitFor()
>  * Thus, the two processes are waiting for each other and fall into a deadlock
>  
>  
> The following setup will lead to a deadlock:
>  
> A jar containing the following Main application:
> {code:java}
> object Main extends App {
>   import scala.collection.JavaConverters._
>   val str = Source.fromInputStream(this.getClass.getResourceAsStream("/1mb.txt")).mkString
>   System.err.println(str)
> }
> {code}
> The following NiFi Flow:
>  
> !Screen Shot 2018-03-28 at 15.34.36.png!
>  
> Configuration for ExecuteStreamCommand:
>  
> !Screen Shot 2018-03-28 at 15.36.02.png!
>  
> The script is simply containing a call to the jar: 
> {code:java}
> java -jar stderr.jar
> {code}
>  
> Once the processor calls the script, it appears as "processing" indefinitely and can only be stopped by restarting NiFi.
>  
> I already have a running solution that I will publish as soon as possible.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)