What's it all about, Alfie?

While trying to figure out a problem with the scaling, I was getting a bunch of BindExceptions and they seemed to point to this point in the jruby-1.7.0 code:

  try {
    // This is a bit convoluted because (1) SocketChannel.bind
    // is only in jdk 7 and (2) Socket.getChannel() seems to
    // return null in some cases
    channel = SocketChannel.open();
    Socket socket = channel.socket();
 
    if (localHost != null) {
      socket.bind( new InetSocketAddress(
                            InetAddress.getByName(localHost),
                            localPort) );
    }
 
    try {
      // Do this nonblocking so we can be interrupted
      channel.configureBlocking(false);
      channel.connect( new InetSocketAddress(
                            InetAddress.getByName(remoteHost),
                            remotePort) );
      context.getThread().select(channel, this, SelectionKey.OP_CONNECT);
      channel.finishConnect();
 
      // only try to set blocking back if we succeeded to finish connecting
      channel.configureBlocking(true);

If I was getting bind exceptions, then it had to be coming from line 104 - after all, that's the call to bind(). The problem was, this really needed to be preceded with a call to set SO_REUSEADDR to true so that we didn't have these kinds of issues.

Something like this:

  try {
    // This is a bit convoluted because (1) SocketChannel.bind
    // is only in jdk 7 and (2) Socket.getChannel() seems to
    // return null in some cases
    channel = SocketChannel.open();
    Socket socket = channel.socket();
 
    if (localHost != null) {
      socket.setReuseAddress(true);
      socket.bind( new InetSocketAddress(
                            InetAddress.getByName(localHost),
                            localPort) );
    }
 
    try {
      // Do this nonblocking so we can be interrupted
      channel.configureBlocking(false);
      channel.connect( new InetSocketAddress(
                            InetAddress.getByName(remoteHost),
                            remotePort) );
      context.getThread().select(channel, this, SelectionKey.OP_CONNECT);
      channel.finishConnect();
 
      // only try to set blocking back if we succeeded to finish connecting
      channel.configureBlocking(true);

Simple change, but it'd make a huge difference to the operation of the socket. So I submitted a request to the JRuby team.

After a little bit, I realized that I needed to try and build this all myself, and see if I couldn't just prove the problem for myself. The difficulty was - How to build JRuby?

Turns out, it's not all that hard. First, fork the code on GitHub so you can issue Pull Requests with the changed code. Then, follow the directions to build everything about JRuby:

  $ git clone git://github.com/drbobbeaty/jruby.git
  $ cd jruby
  $ ant
  $ ant jar-complete
  $ ant dist

It should all build just fine. Then check everything in, and push it up to GitHub. Next, you need to tell rvm to build a new version of ruby from that GitHub repo:

  $ rvm get head
  $ rvm reinstall jruby-head --url git://github.com/

And we're almost done… Update the Gemfile to have the paths to the jruby-jars file where you built it, and then update the .rvmrc. I was able to get things running and even packaging a jar file for our deployment.

Hacking on the language. That's a first for me. Quite a fun experience.

What I noticed was that it wasn't the bind on line 104 - it was the connect on line 113. Java returned the BindException as a general Can't get the endpoint, and I found this out by putting in the catch statements and logging the host and port of the exception. This was very illuminating, and I'm very glad I did it.

I'm going to even send a pull request to see if they'll take it. It's a very useful debugging tool.

This entry was posted on Thursday, November 8th, 2012 at 2:32 pm and is filed under Coding, Open Source Software. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.