[
https://issues.apache.org/jira/browse/LUCENE-6530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14576687#comment-14576687
]
Uwe Schindler commented on LUCENE-6530:
---------------------------------------
bq. I never found process builder to be quite what I needed, to be honest.
Same here. I just think that you might get it better.
bq. Well, it can't be an output stream because then you could redirect
within-process (to a byte array, for example).
It could be if it would do "the right thing" internally (spawn a thread that
copies stuff like our pumper). The current API is just inconsistent and "too
low level" for a real Java API - although it used fluent style from the
beginning!
I cleaned up the code a bit and removed useless stuff. The issue did not do
what it said initially, but was still worth a try!
> 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]
