It would probably be best to retain support for SPARK_JAVA_OPTS in
ClientBase though..for developers that may have been using it.
On Wed, Apr 23, 2014 at 6:26 PM, Nishkam Ravi wrote:
> Bit of a race condition here it seems. Patrick made a few changes
> yesterday around the same time as I did (i
Bit of a race condition here it seems. Patrick made a few changes yesterday
around the same time as I did (in ClientBase.scala):
for ((k, v) <- sys.props.filterKeys(_.startsWith("spark")))
{ JAVA_OPTS += "-D" + k + "=" + "\\\"" + v + "\\\"" }
This would allow JAVA_OPTS to be passed on the command
Sorry, I misread - I meant SPARK_JAVA_OPTS - not JAVA_OPTS.
See here : https://issues.apache.org/jira/browse/SPARK-1588
Regards,
Mridul
On Wed, Apr 23, 2014 at 6:37 PM, Mridul Muralidharan wrote:
> This breaks all existing jobs which are not using spark-submit.
> The consensus was not to break c
can you be more specific? What breaks existing jobs? If you are referring to
my comment, SPARK_JAVA_OPTS still works but I think the intent is to move away
from it.
Tom
On Wednesday, April 23, 2014 8:07 AM, Mridul Muralidharan
wrote:
This breaks all existing jobs which are not using spark
This breaks all existing jobs which are not using spark-submit.
The consensus was not to break compatibility unless there was an overriding
reason to do so
On Apr 23, 2014 6:32 PM, "Thomas Graves (JIRA)" wrote:
>
> [
> https://issues.apache.org/jira/browse/SPARK-1576?page=com.atlassian.jira.p
