-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
init.d/trinidad interprets JAVA_MEM environment variable differently than jruby does #26
Comments
Hey Tim, I'm sorry but this seems a bit weird to me and thus I'm not sure I'd like to advocate such usage ... Seems to me that your use-case might be solved either by using the daemon extension instead (thus eliminating the init.d script since you're using it to manually provide env variables). Or moving Also please note that there are tons of other JVM tunning env variables that you might change on the command line but won't be copied to the Trinidad JVM process Bundler execs ... |
Hi Karol, My use case may seem weird but the bigger problem is that init.d/trinidad is using an environment variable differently than jruby is. This can cause other problems, for example, if someone places JAVA_MEM in the bashrc of the user account that both runs init.d/trinidad and runs jruby. IMHO, environment variables should not be reused for different purposes like this. I really think this is a bug in init.d/trinidad but I know you just can't change the environment variable name as that will break backward compatibility. That is why I am offering a solution of an alternate environment variable (the old one can be deprecated or not as you wish) as a transition. Yes, there are other JVM tuning env variables that can be set, but JAVA_MEM is currently the only way to tell init.d/trinidad to set -Xmx. If you don't set JAVA_MEM, init.d/trinidad will use -Xmx500m. One has no choice but to use JAVA_MEM if one wants to change -Xmx. I'll continue to use my branch for now as I have it working, and it works well for my setup which requires no root access to start or stop the server. I already have trinidad in my Gemfile for development and I prefer to use it out of there for production as the version is more easily kept in sync (via my app's Gemfile.lock) not only across development and my production server, but my staging servers as well. |
Thanks for getting back to me Tim, I must emphasize that I only pointed out (quite subjectively :)) how I'd approach this "issue" of yours. Quite forgot about the original cause you've described (the |
084eb3d should do it, let me know if you have any issues with the change (see the commit message for details) |
This change works for me! Thanks Karol! |
Hello.
I am starting and stopping init.d/trinidad from inside bundle exec as I have trinidad installed using 'bundle install --deployment'. For example:
bundle exec /opt/jux/apps/trinidad/init.d/trinidad start
When I set JAVA_MEM, it is interpreted differently by jruby (as started by bundler) than it is in init.d/trinidad making it impossible to run init.d/trinidad inside a bundle exec:
Further investigation shows that jruby expects JAVA_MEM to be the full option (whereas init.d/trinidad expects only the size):
The text was updated successfully, but these errors were encountered: