jruby --ng-server dies when JRUBY_OPTS="--1.9" is set

Changing JRUBY_OPTS="" works fine too. So the issue seems to be localised to using v1.9 compatibility mode in jruby 1.6.0.

It's probably a bug in processing JRUBY_OPTS along with --ng-server. I suspect that we are passing --1.9 as some sort of address to nailgun.

I suggest sanitizing JRUBY_OPTS before running with --ng-server.

Keep in mind that you can dictate which language mode to run on the client side:

[system] ~ $ jruby --ng -e 'puts RUBY_DESCRIPTION'
jruby 1.6.0 (ruby 1.8.7 patchlevel 330) (2011-03-15 f3b6154) (Java HotSpot(TM) 64-Bit Server VM 1.6.0_24) [darwin-x86_64-java]
[system] ~ $ jruby --1.9 --ng -e 'puts RUBY_DESCRIPTION'
jruby 1.6.0 (ruby 1.9.2 patchlevel 136) (2011-03-15 f3b6154) (Java HotSpot(TM) 64-Bit Server VM 1.6.0_24) [darwin-x86_64-java]

Setting component to launcher, since the bash script (nor the experimental bourne shell compat script) doesn't exhibit this behavior.

The exception is also dependent on network configuration. In some cases, I got (masked IP address):

$ JRUBY_OPTS='--1.9' jruby --ng-server
NGServer started on NNN.NNN.NNN.NNN, port 2113.
java.net.BindException: Can't assign requested address
	at java.net.PlainSocketImpl.socketBind(Native Method)
	at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:383)
	at java.net.ServerSocket.bind(ServerSocket.java:328)
	at java.net.ServerSocket.<init>(ServerSocket.java:194)
	at com.martiansoftware.nailgun.NGServer.run(Unknown Source)
	at java.lang.Thread.run(Thread.java:680)
com.martiansoftware.nailgun.builtins.NGAlias: 0/0
com.martiansoftware.nailgun.builtins.NGClasspath: 0/0
com.martiansoftware.nailgun.builtins.NGServerStats: 0/0
com.martiansoftware.nailgun.builtins.NGStop: 0/0
com.martiansoftware.nailgun.builtins.NGVersion: 0/0
NGServer shut down.

I'm seeing this on ubuntu 10.04 with jruby-1.6.1

Essentially this is blocking further moves to use JRuby - I'd need to set this up at the system level via rvm after_use hook.

Hopefully the impotance can be elevated.

Can you elaborate on how you're using the 1.9 mode and nailgun server under RVM?

I have shown a couple of clear workarounds. How do they fall short for you?

Well, I'm not because of this bug
But here is what I wanted to do:

Install RVM
Install Jruby within RVM (RVM builds+installs nailgun)

Now create:

            cat <<EOT >~/.rvm/hooks/after_use
                echo "running: \$rvm_ruby_string"
                if [[ \$rvm_ruby_string =~ jruby ]]; then
                  # blocking --1.9 --fast on http://jira.codehaus.org/browse/JRUBY-5611
                  # initially had javaopts here.
                  jruby --ng-server 2>&1 | logger -is -p "user.notice" -t "nailgun-\$rvm_ruby_string"
                fi
            EOT

Now whenever you start run `rvm use jruby` nailgun is ready for you.
Of course stopping ng is an issue, but more important is being able to pass --1.9 and --fast vis java_opts, both of which prevent nailgun from starting.

The workaorunds fell short because I didn't want to rely on clients doing the right things, rather I wanted to ensure the 1.9 was used - maybe I misunderstand that passing 1.9 to the ng-server enforces?

HTH?

I also experience this problem using jruby 1.7.0.dev using Java HotSpot 1.6.0_27-b07 64-bit Server VM (build 20.2-b06, mixed mode).

For now, please see my comment http://jira.codehaus.org/browse/JRUBY-6246?focusedCommentId=287116&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-287116 in JRUBY-6246.

After trying out a few things, it looks like the problem is not with 1.9 mode per se, but that anything specified in JRUBY_OPTS or on the jruby command line messes up the way in which JRuby builds the command that starts up Nailgun.

As a simple and significant test, I'd recommend specifying "--1.8" and seeing if the same problem will occur (I'm suggesting it will).

In other words, I think the problem is related to specifying options, rather than the specification of any particular option. I believe this is relevant to the following issues:

http://jira.codehaus.org/browse/JRUBY-6246
http://jira.codehaus.org/browse/JRUBY-5611
http://jira.codehaus.org/browse/JRUBY-6251

I'm posting this comment in all three of the above.

• Keith

Oops, I overlooked Hiro Asari's comment on http://jira.codehaus.org/browse/JRUBY-6246, which said that Nailgun could be run in 1.9 mode by using the following:

jruby -Xcompat.version=1.9 --ng-server

I guess there are some options that can be specified safely.

Another comment of his said that the Nailgun's server version does not affect the version in which clients run, so it may not be important to set the version anyway.

• Keith

In general I don't think there should be a reason you'd want to set these properties in the server; they should get passed through from the client. That's the real bug here.

An experiment:

system ~/projects/jruby $ jruby --ng-server &
[3] 41993

system ~/projects/jruby $ NGServer started on all interfaces, port 2113.


system ~/projects/jruby $ jruby --ng -v
jruby 1.7.0.preview2 (1.9.3p203) 2012-09-19 2d497af on Java HotSpot(TM) 64-Bit Server VM 1.7.0_07-b10 [darwin-x86_64]

system ~/projects/jruby $ jruby --ng --1.8 -v
jruby 1.7.0.preview2 (ruby-1.8.7p370) 2012-09-19 2d497af on Java HotSpot(TM) 64-Bit Server VM 1.7.0_07-b10 [darwin-x86_64]

system ~/projects/jruby $ kill -9 %3
[3]-  Killed: 9               jruby --ng-server

system ~/projects/jruby $ jruby --ng -v
connect to Nailgun server: Connection refused

This seems to indicate that options from the client are passing through to the server just fine. Is this not acceptable?

Charlie -

I now understand that my real error was thinking that specifying --1.9 on the Nailgun server command line would be helpful for me.

However, for the sake of other users, I think it would be helpful to communicate this more clearly; currently they get the unknown host error.

I suggest that when --ng-server is used, the script checks to see if --1.8 or --1.9 is specified, and, if so, fails with a message such as this:

—
Invalid option: --1.9; Ruby version may not be specified for the Nailgun server.
Instead, specify the version on the client process you want Nailgun to run for you.
Ex: jruby --1.9 --ng my-script.rb
—

With JRuby 1.6.x, --1.9 is specified to override the default, but in 1.7.x (I presume), --1.8 will be used to override the default of 1.9 when version 1.8 is needed. So this will continue to be an issue, though probably less so.

I would offer a patch myself, but I'm not proficient in shell scripting. I could write something in JRuby, but then I'd be launching an extra JVM to launch the Nailgun server JVM, right? I could write a minimal Java class that checks for this and then passes control to the Nailgun entry point class, but then that new class would need to be the Nailgun server entry point for JRuby – would that be ok, and would you like me to give that a try? If so, would you like to offer any clues as to where to put the class, what to call it, what needs to be changed to call it, where to put tests, which branch/version to fix, etc.?

• Keith

Come to think of it, based on Hiro's message at http://jira.codehaus.org/browse/JRUBY-6246?focusedCommentId=287116&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-287116, it is possible to specify the version, but in a different way:

jruby -Xcompat.version=1.9 --ng-server

So the error message should be something more like this:

—
Invalid option: --1.9; Setting the Ruby version for the Nailgun server does not determine which version is used for client tasks. Instead, specify the version on the client process you want Nailgun to run for you. For example:

jruby --1.9 --ng my-script.rb

However, if you still want to specify the Ruby version for the Nailgun server, then
you can do so as follows:

jruby -Xcompat.version=1.9 --ng-server
or:
jruby -Xcompat.version=1.8 --ng-server

—