Details

    • Type: Bug Bug
    • Status: Open Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: JRuby 1.6
    • Fix Version/s: None
    • Component/s: Launcher
    • Labels:
      None
    • Environment:
      OS X 10.6.6 (Darwin 10.6.0 Darwin Kernel Version 10.6.0: Wed Nov 10 18:13:17 PST 2010; root:xnu-1504.9.26~3/RELEASE_I386 i386 i386)
    • Number of attachments :
      0

      Description

      When you try to start the nailgun server (using jruby 1.6.0) it dies with a java.net.UnknownHostException exception if you have JRUBY_OPTS="--1.9" set and are not root:

      $ jruby --ng-server
      Exception in thread "main" java.net.UnknownHostException: --1.9
      at java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method)
      at java.net.InetAddress$1.lookupAllHostAddr(InetAddress.java:850)
      at java.net.InetAddress.getAddressFromNameService(InetAddress.java:1201)
      at java.net.InetAddress.getAllByName0(InetAddress.java:1154)
      at java.net.InetAddress.getAllByName(InetAddress.java:1084)
      at java.net.InetAddress.getAllByName(InetAddress.java:1020)
      at java.net.InetAddress.getByName(InetAddress.java:970)
      at com.martiansoftware.nailgun.NGServer.main(Unknown Source

      Running the same as root (via sudo) seems to work fine.

      Here's the jruby version info:

      $ jruby -v
      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]

        Issue Links

          Activity

          Hide
          Charl Matthee added a comment -

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

          Show
          Charl Matthee added a comment - Changing JRUBY_OPTS="" works fine too. So the issue seems to be localised to using v1.9 compatibility mode in jruby 1.6.0.
          Hide
          Hiro Asari added a comment -

          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]
          
          Show
          Hiro Asari added a comment - 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]
          Hide
          Hiro Asari added a comment -

          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.
          
          Show
          Hiro Asari added a comment - 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.
          Hide
          Hedgehog added a comment -

          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.

          Show
          Hedgehog added a comment - 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.
          Hide
          Hiro Asari added a comment -

          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?

          Show
          Hiro Asari added a comment - 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?
          Hide
          Hedgehog added a comment - - edited

          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:

          Unable to find source-code formatter for language: bash. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
                      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?

          Show
          Hedgehog added a comment - - edited 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: Unable to find source-code formatter for language: bash. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml 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?
          Hide
          Edward Garson added a comment -

          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).

          Show
          Edward Garson added a comment - 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).
          Show
          Hiro Asari added a comment - 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 .
          Hide
          Keith R. Bennett added a comment -

          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
          Show
          Keith R. Bennett added a comment - 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
          Hide
          Keith R. Bennett added a comment -

          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
          Show
          Keith R. Bennett added a comment - 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
          Hide
          Charles Oliver Nutter added a comment - - edited

          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?

          Show
          Charles Oliver Nutter added a comment - - edited 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?
          Hide
          Keith R. Bennett added a comment -

          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
          Show
          Keith R. Bennett added a comment - 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
          Hide
          Keith R. Bennett added a comment -

          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

          Show
          Keith R. Bennett added a comment - 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 —

            People

            • Assignee:
              Unassigned
              Reporter:
              Charl Matthee
            • Votes:
              4 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated: