I suspect that the answer to this depends on how intensively your site operates and how well written the app is.
I am aware of commercial J2EE apps with serious memory leak issues, requiring reboots of the server every few days. But the issue is not with J2EE, it is an acknowledged problem in the software. Memory leaks in Ruby/Rails apps have to be approached with an understanding that the platform will not prevent bad application code, it only makes it easier to write good application code.
My observation is that Rails is mature enough for "bread and butter" applications, and I am using it for small-scaled systems. But it is still experiencing sufficient teething pains that I do not recommend it for "enterprise applications" where I work (I hate the overused and poorly defined designation "enterprise", but I don't have a better designation at this time of the morning).
The specific issues that I have against Rails are all maturity issues, not core architecture issues. That means that they will be addressed at some point in the future, although they may have a low priority with the Rails developers right now.
1. Rails builds every SQL request dynamically, instead of preparing the request once and then reusing the prepared statement. When I brought this up I was told that "The sanitize SQL method takes care of everything, and not all RDMS's support prepared statements".
The prepare phase of SQL execution can be over 80 percent of CPU usage on the database server, so turning this into a one-time cost at initialization will improve performance and scalability enormously. Sanitize methods increase CPU usage on the application, but do not decrease them on the RDBMS.
What RDBMS' do not support prepared statements? Even MS-Access supports prepared statements in some form.
For "real work" am running against a database on a maxed out IBM 9000 series server that averages 85% CPU usage 24x7, and all of the efficiency tricks in the book have already been applied to existing apps in other platforms.
The system administrator calls me up and says "Your little app is doing 10,000 prepares every hour and impacting everyone else' performance - you'll have to rewrite it before it goes back into production". I know that there are only a few SQL statements being executed over and over in my app, but apps on assorted other platforms will do one prepare each for a few hundred SQL once at deployment, and run for weeks with those few hundred prepares at startup.
I sincerely hope that I have been misinformed on this point, and that I can be corrected. In the meantime, this is a serious showstopper for mid-to large sized shops.
2. A specifc few lines of code in the ActiveRecord are not sensitive to the possibility that the primary key of a system is not necessarily a sequential integer token. This impacts Rails' usefulness in interfacing to some legacy databases and in distributed databases using UUID's for primary keying. The fix is simple but I have not had the time and energy at the same time to submit the fix. I can't claim the flaw, but I have to take the hit for not getting the fix submitted.
This was a showstopper for using rails on a small-scale distributed application I worked on.