Joe Kutner - Deploying with JRuby: Deliver Scalable Web Apps using the JVM

Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and The Pragmatic Programmers, LLC was aware of a trademark claim, the designations have been printed in initial capital letters or in all capitals. The Pragmatic Starter Kit, The Pragmatic Programmer, Pragmatic Programming, Pragmatic Bookshelf and the linking g device are trademarks of The Pragmatic Programmers, LLC.

Every precaution was taken in the preparation of this book. However, the publisher assumes no responsibility for errors or omissions, or for damages that may result from the use of information (including program listings) contained herein.

Our Pragmatic courses, workshops, and other products can help you and your team create better software and have more fun. For more information, as well as the latest Pragmatic titles, please visit us at http://pragprog.com.

Its a remarkable feeling to have other people offer their time and energy to help improve a project that is your own creation. I have been fortunate enough to experience this feeling multiple times over the course of writing this book, so it is important that I try to thank the people who helped make it possible.

I must first thank the reviewers of my book who do not know me. I was shocked by the attention to detail and wise feedback they provided in making my book a finished product. Thank you to Jeff Holland, Matt Margolis, Stephen Wolff, Sam Rose, Tibor Simic, Frederico Tomassetti, Charley Stran, Ian Dees, Kevin Gisi, Wil Moore III, and the dozens of people who reported errata while this book was in beta. I consider you all to be my friends!

Thank you to my wonderful colleagues for their experience, wisdom, and editorial feedback as I worked on this project. They helped me in both the proposal process and the review process: Lyle Johnson, Matt Blackmon, Joshua Rufer, Bryan Powell, Bret Young, Matt Smith, and Robert Miller. This paragraph does not do our friendship justice. Thank you.

I would also like to thank the staff at the Pragmatic Bookshelf: Susannah Pfalzer, Dave Thomas, Andy Hunt, and probably a whole bunch of other people I dont know about. Above all, thank you to Brian P. Hogan, my editor. You have been fair and kind in dealing with much of the crude prose Ive thrown your way. Thank you for helping me with this book and to become a better writer.

It is also important that I thank the creators of the technologies I have written about. This book would not have been possible without their hard work. Thank you to Charles Nutter, Thomas Enebo, Nick Seiger, and the rest of the JRuby team. You are the most amazing group in all of the open source world. Thank you to David Calavera and Karol Bucek of the Trinidad project. Even during the holiday season, these brilliant programmers made themselves available to answer my questions. Thank you to Ben Browning, Toby Crawley, Bob McWhirter, Lance Ball, Jim Crossley, Marek Goldmann, and the rest of the TorqueBox team. Of this group, I must especially thank Ben and Toby, who also provided me with extremely insightful reviews. I hope that I have done justice to the effort these people have put into the technologies covered by this book. I owe them all my deepest gratitude and a free beverage.

Finally, I would like to thank my wife and son. I could not have completed this project without your love and support.

Your website has just crashed, and youre losing money. The application is built on Rails, runs on MRI, and is served up with Mongrel and Apache. Having this kind of infrastructure means that youre managing more processes than you can count on two hands.

The background jobs are run with Resque, Its going to take some time to figure out which component is the culprit because you have no centralized management interface. Standing up a new server will take almost as long because the infrastructure is so complex. But the website has to get back online if you are going to stay in business.

The problem Ive just described is all too common. It has happened to everyone from small start-ups to large companies that use Rails to serve millions of requests. Their infrastructure is complex, and the myriad components are difficult to manage because they are heterogeneous and decentralized in nature. Even worse, Rubyists have become comfortable with this way of doing things, and many think it is the only way of doing things. But that is not the case.