Here's what am trying to say: In most of the other projects, such as
Hadoop, Pig, Sqoop, Flume, etc., the PROJECT_OPTS is used to specify
Additional JVM arguments rather than application arguments. It has
been the same in Mahout too, so MAHOUT_OPTS wasn't ever intended to be
a way to pass
Hi Harsh,
Yes, I agree with you that there needs to be a way to pass args to the jvm.
As for app args, technically, it isn't necessary to have another env-var
for them, since users can just define them on their own scripts. However,
adding the env-var you suggest, MAHOUT_APP_OPTS, would help
Hi everyone,
It seems MAHOUT_OPTS is not getting picked up when running mahout locally
(MAHOUT_LOCAL=true). This can be fixed by switching the order in which
MAHOUT_OPTS is passed in bin/mahout from:
exec $JAVA $JAVA_HEAP_MAX $MAHOUT_OPTS -classpath $CLASSPATH $CLASS $@
to:
exec $JAVA
Hi Mario,
Could you create a JIRA ticket for that, and submit your diff as a patch if
possible?
http://issues.apache.org/jira/browse/MAHOUT
Best,
Gokhan
On Sat, Aug 31, 2013 at 8:56 PM, Mario Rodriguez mario.rod...@gmail.comwrote:
Hi everyone,
It seems MAHOUT_OPTS is not getting picked up
I don't quite know what its used for, but that order change can be
considered incompatible, mainly cause in its current form it is (and
doubles up) applying directly to the JVM that launches Mahout, but the
changed form makes it into application-only arguments.
On Sun, Sep 1, 2013 at 1:05 AM,
What I'm passing in MAHOUT_OPTS
On Sat, Aug 31, 2013 at 2:34 PM, Harsh J ha...@cloudera.com wrote:
I don't quite know what its used for, but that order change can be
considered incompatible, mainly cause in its current form it is (and
doubles up) applying directly to the JVM that launches
What I'm passing in MAHOUT_OPTS are parameters of the same nature of those
being set in bin/mahout:
MAHOUT_OPTS=$MAHOUT_OPTS -Dhadoop.log.dir=$MAHOUT_LOG_DIR
MAHOUT_OPTS=$MAHOUT_OPTS -Dhadoop.log.file=$MAHOUT_LOGFILE
MAHOUT_OPTS=$MAHOUT_OPTS -Dmapred.min.split.size=512MB
MAHOUT_OPTS=$MAHOUT_OPTS
