[
https://issues.apache.org/jira/browse/NIFI-5024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16473785#comment-16473785
]
ASF GitHub Bot commented on NIFI-5024:
--------------------------------------
Github user nsanglar commented on a diff in the pull request:
https://github.com/apache/nifi/pull/2594#discussion_r187841413
--- Diff:
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/ExecuteStreamCommand.java
---
@@ -382,10 +389,10 @@ public void onTrigger(ProcessContext context, final
ProcessSession session) thro
Map<String, String> attributes = new HashMap<>();
final StringBuilder strBldr = new StringBuilder();
- try {
- String line;
- while ((line = bufferedReader.readLine()) != null) {
- strBldr.append(line).append("\n");
+ try (final InputStream is = new FileInputStream(errorOut)) {
--- End diff --
Strange, the link is not working for me either anymore. There are some
pointers on this stackoverflow thread:
https://stackoverflow.com/questions/16983372/why-does-process-hang-if-the-parent-does-not-consume-stdout-stderr-in-java
The difference is that by writing to a file, you bypass the OS pipe for
stderr, and therefore it does not block.
By the way if you execute `TestExecuteStreamCommand` with the old code, you
will be able to reproduce the deadlock even with unit tests.
> 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)
