JRuby server


I spent some time on the flight to SF hacking on an idea I’ve had for a while. The result was checked in yesterday in JRuby trunk, and the important files are bin/jrubysrv and bin/jrubycli. This is still quite experimental, and only guaranteed to work in *NIX environments right now.

So, what is it? Well, if you don’t want the overhead of running one JVM for each JRuby process, these two commands allow you to start a JVM that listens on a specific localhost port, and then you can send JRuby commands to that port. You need a key as password, otherwise the process will fail. Right now, this isn’t as high security as it should be, since the key is passed as a command line parameter. This is still not that big of a problem, since the most common scenario is to start a bunch of things, and then not start anything more. Let me illustrate what you can do with a very simple example.

Say that you have a Rails application, and Mongrel for JRuby installed. Go the the base directory of your Rails app and do this:

jrubysrv -p 20202 -k secretkey &
jrubycli -p 20202 -k secretkey -S mongrel_rails -p 4000
jrubycli -p 20202 -k secretkey -S mongrel_rails -p 4001
jrubycli -p 20202 -k secretkey -S mongrel_rails -p 4002
jrubycli -p 20202 -k secretkey -n

Now, if you are patient, in a while there will be three Mongrels running, listening on ports 4000, 4001 and 4002. And they will run inside the same JVM, but in different JRuby runtimes. Quite neat, and very simple. You may wonder about the last command, with the -n flag. That flag tells the JRuby server running at port 20202 to not start any more JRuby processes. In this way, you can start what you need, and then close it down. Due to problems with thread scheduling and safety, I haven’t implemented a way to kill a single runtime. What you instead need to do is use jrubycli with the -t flag, which will kill the whole JRuby server.

Stay tuned for my next post, on what I’ve actually used this functionality to create. (If you have some slight amount of imagination, you should be able to guess from this blog post…)

But now, of to the races. Or CommunityOne in this case. See you there.



San Francisco and Portland


Tomorrow morning I’ll leave Stockholm for San Francisco. I’ll be arriving 5:ish PM at SFO and will stay at the Handlery Union Square Hotel. I will not present at either JavaOne or RailsConf, though, so I will have a fair amount of time for fun stuff. I will attend the RedMonk unconference at CommunityOne, participate in the DynLang event, and then attend regular JavaOne. If you see me (I’ll be wearing my black hat…), please say hi!

Next Saturday me and my coworkers will move out of SF and take a car to Portland, where we plan to arrive on the following Tuesday or Wednesday, just in time for RailsConf. We leave from Portland early Monday after the conference.

Hope to see many of you there! It will be exciting, that’s for sure. I will also try to report as much as possible from all events.



JRuby at TheServerSide Java Symposium – Europe



Not sure if I’ve mentioned this, but I will represent JRuby at TheServerSide Java Symposium – Europe, in Barcelona, June 27-29. I will give one technical session on JRuby, and one BOF on how to deploy JRuby on Rails applications, both which should be quite exciting.

There are also a number of other nice presentations, so try to get to Barcelona!



Ye Zheng joins ThoughtWorks


Sorry if the title gives it away. I’ve been holding quiet about this for almost a month, but now it’s official. Ye Zheng (more famous as dreamhead), who is one of the core developers of XRuby, have joined ThoughtWorks, and will begin work in China in May. He will be much involved in all things Ruby, and will also work on XRuby and JRuby, so we will probably be working close together. I have the highest respect for Ye Zheng and look forward to working with him. He single handedly rewrote most of the runtime in XRuby for the last release, which is not a small feat.

If you read Chinese, you can read more about it at his blog at http://dreamhead.blogbus.com/logs/5155305.html



JRuby 0.9.9 released


The JRuby team is happy to announce that 0.9.9 has now been released. This release have seen much focus on compatibility with Ruby 1.8, and also making the Java Integration features more solid. We are gearing up for a 1.0-release, and 0.9.9 should be pretty close to what you can expect from 1.0, so now is the time to start testing your applications on JRuby in earnest.

Homepage: http://www.jruby.org/
Download: http://dist.codehaus.org/jruby/

Some of the most important points of this release:

  • Major compatibility and performance overhaul of String, Array, Hash
  • Many YAML and Marshalling issues have been fixed
  • Java Integration overhaul fixing many outstanding issues
  • 180 Jira issues resolved
  • Several more bottlenecks removed
  • Rails applications like Mephisto and plugins like Goldberg are running without hitches
  • Performance has improved by 40% over 0.9.8 based on YARV benchmarks

In response to all the things that needs doing before 1.0, we have decide to add two new committers to the team. Marcin Mielżyński and Bill Dortch have both done some incredibly nice things for the JRuby project, and we’re very happy about them joining up as core developers.

In conjunction with 0.9.9, Rails-integration will see a new release, that improves many parts of it. Since we’ve actually started using Rails-integration in more places, we have also noticed things that need to be improved; the new release is very good.

ActiveRecord-JDBC 0.2.4 will also be released very soon. We have made some major changes, and much of the core have been rewritten. These changes make MySQL fully compatible with ActiveRecord, and we are working hard on improving support for other databases. Hopefully, the 0.2.4 release will mean Derby support is more or less complete too.



Practical JRuby on Rails


The time of waiting is over. I have hinted over and over that I’ve been doing some stuff that take lots of time. The first part of this was interviewing for ThoughtWorks, and I told you that a month back. And now I can finally tell you what’s keeping me so busy, that I can’t blog as much as I used to:

I am writing Practical JRuby on Rails: Web 2.0 projects for APress. I have been since late December, and the book is due to be published in October. But you can actually preorder the book today, from Amazon, here.



Me presenting JRuby


I totally forgot about this; 4-6 weeks ago, I did a presentation for the local Railsgroup here in Stockholm; since Dr Nic was there, I decided to improve it in English. And Dr Nic did us the service of taping the whole presentation; I was sick at the time, it’s a short presentation about what’s new in JRuby, but it could still be potentially interesting for some of you.

It’s available at Google Video, here.



The State of JRuby


It’s been sort of quiet on the JRuby front for a few weeks, so I thought I’d give a heads up on what things we’re working on at the moment. At the moment, we’re planning to release 0.9.9 sometime next week. At that point, several things we’re working on right now should be fixed.

  • There is a problem with deterministic threading in JRuby, which results in timeout errors sometimes escaping out of their rescue nodes. This is very serious for long running applications and Charles is hard at work providing better Thread semantics for us. The problem is that it’s very hard to match MRI’s green thread functionality with real native threads.
  • Thomas is hard at work with one of his gigantic refactorings. This time the goal is to remove most of ThreadContext and make many parts of the call chain and block invocation chains easier to work with.
  • Marcin have been working for some weeks now on a port of the hash implementation in MRI, and a corresponding rewrite of RubyHash. At the same time, he’s hard at work rewriting RubyString to allow COW (copy-on-write) semantics. This could potentially improve performance and also make JRuby less memory intense.
  • Earlier this week, we identified and fixed two very serious memory leaks. The second of these caused large leakage in all Rails applications using Cgi::Session for session data (which is almost all JRuby on Rails applications, except those running in Rails-integration). At the moment we don’t see any leaking for Rails applications, so the situation looks good. (Both of these leaks were found with the help of Java monitoring tools, like JConsole, jmap and jhat. Very useful things.)
  • I have been doing some serious YAML fixes these last days, with the result that our YAML situation is better than ever. It even handles recursive objects correctly. (Which is a pain in Java. In C it’s easy, though.)

Overall, we’re working very hard on the last, quirky compatibility issues right now; we have a few different, large Rails applications that we use to identify strange issues. And also, more and more people are trying their applications on JRuby, which means we get better (and more) bug reports. This is really great.

After 0.9.9 has been released, we’re planning on finishing up remaining important bugs. I’m also very keen about getting more databases running really well with Rails. We will try to get Continous Integration set up for these too.



ActiveHibernate – Any takers?


This is a call for action. JRuby on Rails is getting more stable each day, and JRuby performance is consistently improving. This means that JRuby on Rails is well on the path of becoming a viable platform for several kinds of web development.

ActiveRecord-JDBC is central to this, and it’s a good project and works very well. Within the limitations of ActiveRecord, of course. So, I’m thinking (and this is by all means not a new thought), that I would like to have the rest of Rails, but using Hibernate as backend. With JRuby approaching 1.0 fast, ActiveHibernate seems like a neat project. The only problem is time. So why is ActiveHibernate tempting? Well, for all those situations where ActiveRecord really doesn’t fit; composite keys, complicated legacy systems. Or databases where you would like to use prepared statements for everything. Or get really nice speed.

What needs to be done? For it to be really useful, there are few points: First, a Hibernate extension that serializes and deserializes into RubyObjects. By doing it that way, there is no need to create Java bean classes. Secondly, provide all the useful help functionality around the Hibernate implementation, that AR users have gotten used to. This includes things like validations, automatic handling of updates and inserts, and is generally about doing a good Ruby interface around Hibernate. This also includes creating a good way of configuring Hibernate without having to resort to the XML. Maybe using YAML? Or a Ruby DSL? After that has been done, the final point is easy: get mind share and start doing applications with it! I for one know that I would like to use such a project!



Can your Ruby do this?


Recipe (should be baked with Java 6 for maximum pleasure):

  1. Take one large Rails application with good Selenium test base
  2. Convert database configuration to use JDBC
  3. Start a selenium proxy with “jake test:selenium_proxy”
  4. Start acceptance testing from another window with “jake test:acceptance”
  5. In yet another window, write “jconsole”
  6. Choose your application

What do you get?

You get this for free, just by running JRuby with Java 6. You can attach to any Java process at all. Remotely too. And get this kind of information. Can your Ruby do that?