[ 
https://issues.apache.org/jira/browse/SOLR-6387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hoss Man updated SOLR-6387:
---------------------------

    Description: 
Various versions of the Sun/Oracle/OpenJDK JVM have issues executing new 
processes if the default langauge of the JVM is "Turkish".

The root bug reports of this affecting Runtime.exec() are here...

* https://bugs.openjdk.java.net/browse/JDK-8047340
* https://bugs.openjdk.java.net/browse/JDK-8055301

On systems runining the affected JVMs, with a default langauge of "Turkish", 
this problem has historically manifested itself in Solr in a few ways:
* SystemInfoHandler would throw nasty exceptions on these systems due to an 
attempt at conditionally executing some native process to check system stats
* RunExecutableListener would fail cryptically
* some solr tests involving either the SystemInfoHandler or the Hadoop 
MapReduce code would fail if the test framework randomly selected a turkish 
language based locale.

Starting with Solr 4.10, We have worked around this jvm bug in Solr in 3 ways:
* RunExecutableListener makes it more clear in the logs why it can't be used
* SystemInfoHandler traps and ignores any Error related to "posix_span" in the 
same way it traps and ignores other errors related to it's conditional attempts 
at exec'ing (ie: permission problems, executable not found ,etc...)
* our map reduce based tests that depend on exec'ing external processes now 
skip themselves automatically if a turkish local is randomly selected.

Users affected by this issue who, for whatever reasons, can not upgrade to Solr 
4.10, may wish to consider setting the "jdk.lang.Process.launchMechanism" 
system property explicitly (see below)

{panel:title=original issue report}

Jenkin's tests occasionally fail with the following cryptic error...

{noformat}
java.lang.Error: posix_spawn is not a supported process launch mechanism on 
this platform.
        at 
__randomizedtesting.SeedInfo.seed([9219CAA3BCAA7365:7F07719937A772E1]:0)
        at java.lang.UNIXProcess$1.run(UNIXProcess.java:104)
        at java.lang.UNIXProcess$1.run(UNIXProcess.java:93)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.lang.UNIXProcess.<clinit>(UNIXProcess.java:91)
        at java.lang.ProcessImpl.start(ProcessImpl.java:130)
        at java.lang.ProcessBuilder.start(ProcessBuilder.java:1028)
        at java.lang.Runtime.exec(Runtime.java:617)
{noformat}

A commonality of most of these failures is that the turkish locale has been 
randomly selected, and apparently the Runtime.exec is busted whtn you use 
turkish...

http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8047340
http://java.thedizzyheights.com/2014/07/java-error-posix_spawn-is-not-a-supported-process-launch-mechanism-on-this-platform-when-trying-to-spawn-a-process/

We should consider hardcoding the "jdk.lang.Process.launchMechanism" sys 
property mentioned as a workarround in the jdk bug report
{panel}

  was:
Jenkin's tests occasionally fail with the following cryptic error...

{noformat}
java.lang.Error: posix_spawn is not a supported process launch mechanism on 
this platform.
        at 
__randomizedtesting.SeedInfo.seed([9219CAA3BCAA7365:7F07719937A772E1]:0)
        at java.lang.UNIXProcess$1.run(UNIXProcess.java:104)
        at java.lang.UNIXProcess$1.run(UNIXProcess.java:93)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.lang.UNIXProcess.<clinit>(UNIXProcess.java:91)
        at java.lang.ProcessImpl.start(ProcessImpl.java:130)
        at java.lang.ProcessBuilder.start(ProcessBuilder.java:1028)
        at java.lang.Runtime.exec(Runtime.java:617)
{noformat}

A commonality of most of these failures is that the turkish locale has been 
randomly selected, and apparently the Runtime.exec is busted whtn you use 
turkish...

http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8047340
http://java.thedizzyheights.com/2014/07/java-error-posix_spawn-is-not-a-supported-process-launch-mechanism-on-this-platform-when-trying-to-spawn-a-process/

We should consider hardcoding the "jdk.lang.Process.launchMechanism" sys 
property mentioned as a workarround in the jdk bug report

        Summary: Solr specific work around for JDK bug #8047340: posix_spawn 
error with turkish locale  (was: Add work around for JDK bug #8047340 ?)

updated issue summary & description to be more helpful to people who follow the 
links in the new error/assume messages

> Solr specific work around for JDK bug #8047340: posix_spawn error with 
> turkish locale
> -------------------------------------------------------------------------------------
>
>                 Key: SOLR-6387
>                 URL: https://issues.apache.org/jira/browse/SOLR-6387
>             Project: Solr
>          Issue Type: Bug
>         Environment: Linux, MacOSX, POSIX in general
>            Reporter: Hoss Man
>            Assignee: Uwe Schindler
>            Priority: Minor
>              Labels: Java7, Java8
>             Fix For: 5.0, 4.10
>
>         Attachments: SOLR-6387.patch, SOLR-6387.patch
>
>
> Various versions of the Sun/Oracle/OpenJDK JVM have issues executing new 
> processes if the default langauge of the JVM is "Turkish".
> The root bug reports of this affecting Runtime.exec() are here...
> * https://bugs.openjdk.java.net/browse/JDK-8047340
> * https://bugs.openjdk.java.net/browse/JDK-8055301
> On systems runining the affected JVMs, with a default langauge of "Turkish", 
> this problem has historically manifested itself in Solr in a few ways:
> * SystemInfoHandler would throw nasty exceptions on these systems due to an 
> attempt at conditionally executing some native process to check system stats
> * RunExecutableListener would fail cryptically
> * some solr tests involving either the SystemInfoHandler or the Hadoop 
> MapReduce code would fail if the test framework randomly selected a turkish 
> language based locale.
> Starting with Solr 4.10, We have worked around this jvm bug in Solr in 3 ways:
> * RunExecutableListener makes it more clear in the logs why it can't be used
> * SystemInfoHandler traps and ignores any Error related to "posix_span" in 
> the same way it traps and ignores other errors related to it's conditional 
> attempts at exec'ing (ie: permission problems, executable not found ,etc...)
> * our map reduce based tests that depend on exec'ing external processes now 
> skip themselves automatically if a turkish local is randomly selected.
> Users affected by this issue who, for whatever reasons, can not upgrade to 
> Solr 4.10, may wish to consider setting the 
> "jdk.lang.Process.launchMechanism" system property explicitly (see below)
> {panel:title=original issue report}
> Jenkin's tests occasionally fail with the following cryptic error...
> {noformat}
> java.lang.Error: posix_spawn is not a supported process launch mechanism on 
> this platform.
>         at 
> __randomizedtesting.SeedInfo.seed([9219CAA3BCAA7365:7F07719937A772E1]:0)
>         at java.lang.UNIXProcess$1.run(UNIXProcess.java:104)
>         at java.lang.UNIXProcess$1.run(UNIXProcess.java:93)
>         at java.security.AccessController.doPrivileged(Native Method)
>         at java.lang.UNIXProcess.<clinit>(UNIXProcess.java:91)
>         at java.lang.ProcessImpl.start(ProcessImpl.java:130)
>         at java.lang.ProcessBuilder.start(ProcessBuilder.java:1028)
>         at java.lang.Runtime.exec(Runtime.java:617)
> {noformat}
> A commonality of most of these failures is that the turkish locale has been 
> randomly selected, and apparently the Runtime.exec is busted whtn you use 
> turkish...
> http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8047340
> http://java.thedizzyheights.com/2014/07/java-error-posix_spawn-is-not-a-supported-process-launch-mechanism-on-this-platform-when-trying-to-spawn-a-process/
> We should consider hardcoding the "jdk.lang.Process.launchMechanism" sys 
> property mentioned as a workarround in the jdk bug report
> {panel}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to