Josh Peek officially joins the Rails core
Posted by David August 16, 2008 @ 08:03 PM
Josh Peek has been a defacto Rails core committer for a while, but for some reason we’ve never actually made the appointment official. So here it goes: Josh Peek is the latest Rails core team member. Three cheers hurray!
Josh has been working on a Google Summer of Code project to bring thread safety to Rails and is just about ready to wrap it up. Rails 2.2 will be thread safe thanks to the work that Josh has put into it.
Of more importance, though, is the significant effort put into making things faster and cleaner as part of that push. The actual thread safety won’t really matter much to most people, but it’ll surely look nice on your enterprisey check list of Features Your Framework Must Have To Get Play Around Here.
In any case, please welcome Josh!
Yay, good job Josh!
Well deserved Josh.
First ModRails and now thread safety? ::sniff:: ::sniff:: Our little framework is all grown up.
Josh, Welcome, and thank you for your work on thread safety :)
Welcome Josh, gratz ! and nice work so far !
Thread safe at last!
Well done Josh!
Thread safety is huge. Its not as huge as it should be because we don’t have kernel threads yet in Ruby, but this is a big step in the right direction. Nice work Josh.
Well deserved and long-awaited (by me, at least)! Congrats Josh and keep up the awesome work :)
Much congratulations, and thanks for all your hard work!
Hopefully this means some kind merb style deferred request system makes it into the release also.
Good work! :)
This is a huge step forward. Good work Josh. This means that we can finally do things like comet with rails without spawning a few hundred mongrels.
“The actual thread safety won’t really matter much to most people,”
Uh, what?
This only means that Rails can be taken seriously now. Won’t really matter much?
@v, @S2: What DHH meant is that threads are not necessary for Rails to be memory/multi-core efficient and to be concurrent. Concurrency and multi-core utilization can be achieved by using processes instead of threads, with the added benefit that processes won’t cause threading problems like racing conditions, deadlocks, etc. Memory efficiency can be achieved by using Phusion Passenger in combination with Ruby Enterprise Edition. Check out the FAQ and the graphs at http://www.rubyenterpriseedition.com/
Finally! No more worriing because some requests sleep and thus block a whole mongrel. Like on complicated reporting pages or upload actions where rails just sits there and waits for external processes.
I’m a little worried that some plugins may break, though… But we’ll see.
Buzzword-party!
@Hongli Lai : I think you’re confusing an intentional design decision with a necessity. Rubys threading is poor enough that processes are the only way to go.
It’s still a pain to manage n dozen Mongrels however you slice it, enough that a whole toolchain has grown up around that (which we used to mock the J2EE guys for).
Merb has raised the game here, and Rubinius and JRuby both make it a bigger win to have multithreadable frameworks. Assuming your libraries are good enough, of course ( http://blog.hungrymachine.com/2008/8/6/ruby-and-multi-threaded-mysql-mri-vs-jruby-jdbc-vs-dataobjects-mysql )
Dick Davies: Rubinius is unfortunately just as green-threaded as CRuby, so multi-threaded Rails won’t be a great a boon for folks running on Rubinius.
But there’s a few comments I should make here:
In general, Merb and Rails 2.2+ are going to always use less memory when multiprocessing if they run on JRuby, but the threading fixes will also help reduce the memory load when running off JRuby.
@Dick Davies: You don’t have to manage Mongrels, that’s what Phusion Passenger is for. :) And managing Mongrels has got nothing to do with threads. They could have written a process manager so that the cluster doesn’t have to be managed, but they didn’t.
Still, not all applications and Rails plugins are thread-safe. Not all developers know how to write thread-safe code. People often join #jruby and ask why their code throws a Java ConcurrentModificationException—turns out they didn’t know what locks are. And using threads still means that if one thread crashes, the entire application crashes.
I would also like to note that alot of my work was focused on preload caches on bootup. This avoids the problem of synchronizes these caches across threads.
However, preloading is a big win for Phusion Passenger. You should save more memory with the next release of Rails. I highly recommend Passenger over a threaded app. There is alot of work that needs to be done on your side to make sure your app is threadsafe. However, you get nearly all the benefits of threads with Passenger but at no cost.
Rails being multi-threaded is a great step forward.
That said, I’m more concerned with things like the mysql gem not being concurrent. Every SQL call from rails stop the ruby interpreter, across different threads and different DB connections, or so it appears.
More details here: http://blog.hungrymachine.com/2008/8/17/ruby-and-multi-threaded-mysql-mri-vs-jruby-jdbc-vs-dataobjects-mysql
Maybe a multi-threaded rails will push to get this fixed though..
Congrats Josh.
Well done, Mr Peek!
Thank you Josh! Green threads in MRI are a huge concurrency win for sites using external API calls where a kernel thread would be too heavy.
Great things. Nice one Josh.
Hongli: of course you have an interest in making sure people understand the value of Passenger and RubyEE, but that statement is simply not true. People occasionally ask about concurrency-related exceptions, but almost always in cases where they are using JRuby explicitly because it can parallelize and they simply haven’t taken care of managing resources they share across threads. The changes to Rails go a long way toward both eliminating shared access to resources and making other cases guard such access. So it’s grows exaggeration to say that people often run into these issues on JRuby since the vast majority of apps and users are able to use threads without issue.
Josh is a machine.
I like Peek almost as much as Poke!
But seriously, congrats, Josh!
@Charles: Sorry, I didn’t mean that they run into concurrency issues in JRuby. I mean that a lot of people aren’t familiar with concurrent programming. The thing about #jruby and ConcurrentModificationException is just an example. :) What I’m saying is that if the underlying framework uses threads, then inexperience programmers can be unpleasantly surprised if they’re not careful.
For example, I can imagine that people would try to cache values into a global Hash, without locking it.
it’s about freakin time, thanks josh peek!
I love you Josh
I can’t wait to see this in combination with some asynchronous MRI database libs 1. Thank you so much! I hope it helps! -=R [1] http://oldmoe.blogspot.com/2008/07/faster-io-for-ruby-with-postgres.html [2] http://github.com/tqbf/asymy/tree/master
Congrats!
Wow, thread safety I mean wow. That is just damn awesome. No more late nights worrying about blocked mongrels.
This is good news for MRI, too-
I wonder if this coupled with some asynch IO libraries [and 1.9 -is rails compatible with 1.9?] could make it nicely multi threaded.http://github.com/tqbf/asymy/tree/master http://oldmoe.blogspot.com/2008/07/faster-io-for-ruby-with-postgres.html
That rocks. Now if we can just combine it with some asynchronous database adapters like asymy…this could rock.
josh siempre estara vivo en los corazones nuestros
Great News and Great Efforts by Josh.
My best wishes.
Can some come out clear guiding me…. How far are we from Rails 2.2…?
Is it worth to go for Rails 2.1 now,or wait a little more for Rails 2.2…?
Thanks
AWESOME!
This will be rad. We learned WAY more than we wanted to about load balancing to get around blocking mongrels at SlideShare.
Josh, if you’re ever in SF I owe you a beer or three!
-jon
well done josh
This is really excellent. Congrats on this great work!
For the record though “can scale” is always on my “enterprisey check list of Features Your Framework Must Have To Get Play Around Here”—it’s much easier and cheaper to scale out a fleet of multithreaded servers.