[
https://issues.apache.org/jira/browse/LUCENE-6530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14576460#comment-14576460
]
Uwe Schindler commented on LUCENE-6530:
---------------------------------------
bq. so you need an action on both sides (write/read) to fill or clean the
pipe's buffer.
I just wonder how the Redirect#to(File out) works internally. Why is it only
File (and not NIO.2 Path), and why not simply an OutputStream. From my own
knowledge about C, you still need some pumping unless you can connect the file
handles directly after forking (which is what they may do). The whole API is
just inconsistent!
> Use Java 7 ProcessBuilder.inheritIO() instead of own ThreadPumper
> -----------------------------------------------------------------
>
> Key: LUCENE-6530
> URL: https://issues.apache.org/jira/browse/LUCENE-6530
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Uwe Schindler
> Assignee: Uwe Schindler
> Priority: Minor
> Labels: Java7
> Fix For: Trunk, 5.3
>
> Attachments: LUCENE-6530.patch, LUCENE-6530.patch
>
>
> In some tests wie spawn separate processes (TestIndexWriterOnJRECrash and
> Solr's IPTables). To capture stdin/stdout/stderr we spawn several threads
> that pump those to stdout/stderr.
> Since Java 7 there is ProcessBuilder.inheritIO() that does this for us
> without any additional threads. We should use this instead. Fix is easy, just
> remove some stuff :-)
> I did the same already for my Codec classloader deadlock test, so this is
> just a followup for the other tests.
> Patch is attached and can be committed to trunk and 5.x.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
