On Aug 18, 3:59 pm, Charles Oliver N. [email protected] wrote:
Multithreading in JRuby doesn’t mean you need to write multi-threaded
Rails apps; it means you get to take advantage of Rails thread-safe
mode (2.2+) to shove as many requests as you possibly can through a
single instance. No other Ruby implementation can do that.
- Charlie
What prevents this from working properly in Ruby 1.9?
Charles Nutter wrote:
[…]
JRuby works fine as a Mongrel process (and if you turn on threadsafe
mode in Rails, your entire site can be a single process).
I’m using Passenger right now, not Mongrel, but I’ll keep that in mind.
There’s
also the glassfish gem, which allows one-command deployment of an
entire app, all in a single process. I think the difficulty of setting
up JRuby on the server has been vastly overstated.$ gem install glassfish
$ glassfish -e productionThat’s it.
That may be worth trying out, then. I don’t think that was available
the last time I looked at JRuby seriously.
[…]
There’s actually a number of people that like NetBeans (or one of the
other IDEs) a lot for Rails work.
I’m well aware of that. I’m not one of them.
And of course if you’re working with
several languages, it does a very good job.
If I were doing a multilanguage project, of course I’d try to find an
IDE that handled them all well. However, I’m not, which means I get to
pick an IDE that is best for what I’m working with. That currently
means no IDE as such for Rails, and probably (speaking hypothetically)
Xcode for Objective-C, Eclipse or perhaps NetBeans for Java…
[…]
Even if you
don’t use those IDEs as anything more than editors, they’re very nice
editors.
No they’re not; in fact, Eclipse and NetBeans both kind of suck as
editors. KomodoEdit blows them both out of the water, and I understand
TextMate blows KomodoEdit out of the water. No word-wrap in Eclipse or
NetBeans? Srsly? What decade is this? 
[…]
You don’t have to deploy to a Java servlet container, and for typical
Rubyists we actually recommend using one of the non-servlet options.
Good to know. I will be the first to admit that I’m no Java expert, so
this is very helpful.
- Charlie
Thanks for the advice on JRuby straight from the horse’s mouth!
Marnen Laibow-Koser
http://www.marnen.org
[email protected]
On Aug 16, 7:29 am, InventoryTrackers [email protected]
wrote:
My two cents.
None of the RMagick stuff with attachment_fu would work when I tried
to use JRuby. They said they had something like JMagick? but nobody I
contacted seemed to use photos in their application???
If you want to use attachment_fu, you can look at image_voodoo, a
JRuby version of image_science…I think that gives you everything you
need.
The RMagick-lookalike project is rmagick4j. It has enough implemented
to pass all of Gruff Graph’s tests, which is pretty good. But it’s not
100%.
On Aug 18, 5:32 pm, Charles Oliver N. [email protected] wrote:
good presentation on the issues in Python:
- Charlie
Makes sense, not sure why I didn’t remember that (especially when I
directly ran into this with a somewhat toyish app that does alot of
CPU intensive work in threaded batches). Thanks.
On Aug 18, 3:58 pm, pharrington [email protected] wrote:
On Aug 18, 3:59 pm, Charles Oliver N. [email protected] wrote:
Multithreading in JRuby doesn’t mean you need to write multi-threaded
Rails apps; it means you get to take advantage of Rails thread-safe
mode (2.2+) to shove as many requests as you possibly can through a
single instance. No other Ruby implementation can do that.What prevents this from working properly in Ruby 1.9?
Ruby 1.9 has a “giant lock” that prevents threads from running in
parallel. So even though they’re native, you’d still need 16 processes
to utilize 16 cores fully. The only implementations to support actual
parallel-executing threads are JRuby, IronRuby, and MacRuby. Of these,
only IronRuby and JRuby run Rails. Of these, only JRuby is production-
ready and fast.
Ruby 1.9 may also suffer from issues common to other GIL-based
systems like Python (giant interpreter lock), since you start to have
the OS scheduler and the GIL scheduler fighting each other. Here’s a
good presentation on the issues in Python:
At 10:45 PM -0700 8/15/09, AlwaysCharging wrote:
Why would anyone use ruby over Jruby? I’m admittedly a noob about all
this stuff, but from what I’ve read jruby seems superior to ruby and
quite a bit faster. What would be the disadvantages of JRuby? I man
it’s possible to use it with rails now, and JRuby is what’s used by
default in netbeans (which is the ide I think I’ve settled on). So
why not JRuby? Would the tutorials be all that different?
I use both MRI and JRuby – often at the same time in the same
project when developing.
One advantage I didn’t see in the thread so for MRI is that the
interpreter starts fast. This is great when starting lots of small
tasks from the console.
Here’s a couple of pluses for JRuby that I haven’t seen mentioned:
It is very easy to make multiple, complete, and isolated Ruby
installation using JRuby. I know there are some tools to make this
easier in MRI – I even wrote a simple one – but this is trivial in
JRuby.
For some rendering operations in development mode JRuby can be 20x
faster.
This is a strange result – in general I’ve found JRuby to be about
twice as fast as MRI in production … but I’d never seen this result
before …
I’ve got a complex Rails application for authoring secondary science
investigations and one of the render tasks generates a composite xml
document that represents all of the objects in an investigation.
Right now the largest investigation is about 350k rendered into xml
and represents over 1100 objects. Roughly that corresponds to about
1100 partial calls.
I have not done ANY work on improving performance in the rendering
speed yet (lots of partials calling partials) and noticed that the
render speed when running in MRI in development mode has gotten very
long as authors have finally started making real investigations.
I put together a benchmark measuring the time to render 11
investigations in xml.
The JRuby results were quite impressive:
Development Production
=======================================
MRI: 849s 30s
JRuby: 35s 18s
The rendering is done with HAML.
I have no idea why rendering in dev mode in MRI is SO slow.
There’s obviously a problem somewhere in the interaction with Rails,
my code, MRI and development mode. But the fact that JRuby running in
development mode renders all 11 Investigations into xml only 15%
slower than MRI in production is great. It also means that when I am
testing or developing these features in the app I run my dev server
in JRuby.
While I plan to work on performance later in most cases in production
the Investigations will be frozen and the xml doc will be served from
a page cache – so performance improvements in rendering are not on
the critical path for the production app.
This is running on Mac OS X 10.5.8 and Rails 2.3.3
MRI and JRuby versions:
$ jruby -v
jruby 1.4.0dev (ruby 1.8.7p174) (2009-08-09 6586) (Java HotSpot™
Client VM 1.5.0_19) [i386-java]
$ ruby -v
ruby 1.8.6 (2008-08-11 patchlevel 287) [universal-darwin9.0]
more details:
http://groups.google.com/group/cc-developers/browse_thread/thread/af4ca01be8eb41ab?hl=en
I believe for Jruby the min and max runtimes need to bet set to 1 for
this to happen and work with config.threadsafe!
AD
On Thu, Aug 27, 2009 at 9:18 AM, Gianluca
Sorry, I still can’t understand how to run rails in thread safe mode
under JRuby (one running instance supporting multiple concurrent
requests).
If I try to enable config.threadsafe! in
config/environments/production.rb under Glassfish Gem my Rails
application still run single threaded.
Here a very simple example (environment is: glassfish gem v. 0.9.5 /
jruby 1.3.1 / rails 2.3.3 / ubuntu 9.04 / notebook centrino dual core /
2gb Ram):
rails concurrent
cd concurrent
script/generate controller test test
edit app/controllers/test_controller.rb, modify source as follow:
class TestController < ApplicationController
def test
@value = Time.now
sleep 10
end
end
edit app/views/test/test.html.erb, modify source as follow:
<%= @value %>
edit config/environments/production.rb, uncomment last line as follow:
config.threadsafe!
edit config/environemt.rbm uncomment frameworks line as follow (no
database, resource, mail support for this very simple
test…):
config.frameworks -= [ :active_record, :active_resource, :action_mailer
]
Now run:
jruby -S gfrake config
edit config/glassfish.yml, modify config as follow (notice 4 runtime
instances !):
environment: production
jruby-runtime-pool:
initial: 4
min: 4
max: 4
And finally start glassfish gem:
jruby -S glassfish
Now, if you try to call 4 times (concurrently) the following url…
http://localhost:3000/test/test
…you must wait 40 seconds for the 4th response…
This is a wrong behaviour because trying the same test under phusion
passenger I wait only 10 seconds for the 4th response
(in fact passenger start up 4 rails processes, 1 for each concurrent
request)…
I want to know if is it possible to run Rails with only one running
instance supporting multiple concurrent requests…
Many thanks in advance…
Many thanks for the suggestion, but the problem is still here…
My runtime configuration now is:
tex@tex-laptop:~xxx$ jruby -S glassfish
Parsing config file: /home/tex/xxx/config/glassfish.yml
Arguments:
runtimes=>1
runtimes_min=>1
runtimes_max=>1
contextroot=>/
environment=>production
app_dir=>/home/tex/xxx
port=>3000
pid=>
log=>/home/tex/xxx/log/production.log
log_console=>false
log_level=>7
daemon=>false
jvm_options=>
domain_dir=>/home/tex/xxx/tmp/.glassfish
Starting GlassFish server at: 127.0.0.1:3000 in production
environment…
Writing log messages to: /home/tex/xxx/log/production.log.
Press Ctrl+C to stop.
The problem is always the same: 40 seconds for the 4th response…
I think I’m the only one on the heart that cannot run rails with JRuby
with multiple concurrent requests, all the other out there seems that
can run it without any problem (maybe I’m unlucky, sigh…)
On Aug 27, 8:18 am, Gianluca T.
[email protected] wrote:
jruby-runtime-pool:
initial: 4
min: 4
max: 4
I think this is your mistake. You told Rails to run in threadsafe
mode, which Glassfish gem will pick up; but then you forced Glassfish
to run with a runtime pool of 4 instances. If you don’t do this it
works fine, and your four concurrent requests all take the same amount
of time (10s) to run because they’re running in parallel.
The only bottleneck you might run into with this contrived example is
that GF by default only has a certain size thread pool, and will start
to park requests until one of the request-processing threads is
available, but you can crank that up too if needed.
I assure you, Rails on JRuby runs great in threadsafe mode, with only
a single runtime. You can crank thousands of requests through a single
instance, something impossible to do with any other Ruby
implementation so far.
Dear All,
I think Ruby and JRuby both have their advantages. It depends on the
environment which one is easier to integrate and maintain.
In a typical Linux-Apache-(Postgres|MySQL)-Ruby environment JRuby with
its additional requirement of Java comes with some
painful extra cost, which can otherwise be avoided. In an
java-enviroment, where part of the stuff should be done with Ruby+Rails
it might be the other way round.
My own observation is that JRuby is slightly faster than Ruby 1.8.7, but
Ruby 1.9 is way faster than that. But it depends on what Java
you use, what you do etc…
I would like to point out that the set of libraries available may be
quite different. Many Ruby-libraries use native c-code and are
unavailable in JRuby.
Another point is that operating-system-functionality is not really
available in Java beyond what can be commonly implemented on
different platforms supported by Java. So they are not easily accessed
in JRuby either. If such stuff is needed, native Ruby is better.
I have even used native Ruby to add Windows- and Linux-specific
functionalities for accessing OS-features needed and hidden in Java
from a Java software.
So I would really recommend to carefully consider which one is better.
Best regards,
Karl
I would worry about changes to the Java language that would affect
JRuby. Ruby implementation is never going to be a big concern of the
Java devs, nor should it be.
On Aug 30, 3:32 pm, AGoofin [email protected] wrote:
I would worry about changes to the Java language that would affect
JRuby. Ruby implementation is never going to be a big concern of the
Java devs, nor should it be.
Changes to the Java languages are extremely unlikely to be anything
but helpful for JRuby. There are also JVM-level features planned for
Java 7 which could help JRuby tremendously. I would not worry at all
about Java changes negatively impacting JRuby, and I should know.
Hej,
I have no doubt that JRuby is good stuff and I actually use it myself.
My own RubyForge-procect (long-decimal) is done in such a way that it
work both in Ruby 1.x and JRuby.
Best regards,
Karl
On Aug 30, 2:34 am, Karl B. [email protected] wrote:
Dear All,
I think Ruby and JRuby both have their advantages. It depends on the
environment which one is easier to integrate and maintain.
In a typical Linux-Apache-(Postgres|MySQL)-Ruby environment JRuby with
its additional requirement of Java comes with some
painful extra cost, which can otherwise be avoided. In an
java-enviroment, where part of the stuff should be done with Ruby+Rails
it might be the other way round.
I think the “cost” of the Java dependency is extremely low. Debian,
Suse, Redhat, Ubuntu…all the Linux distributions how have single-
command installs for Java that “just work”. Pick a “Java 6” or “Java
1.6” version and you’re ready to go. I would dare say it’s at least as
easy as Ruby, and probably easier on peculiar systems that have Java
installs but no supported Ruby install.
It is for this reason JRuby has become the Ruby of choice for a lot of
people on Windows; install Java, unpack JRuby, and you’re done.
My own observation is that JRuby is slightly faster than Ruby 1.8.7, but
Ruby 1.9 is way faster than that. But it depends on what Java
you use, what you do etc…
Java 6+ should always be used for comparison, and if you’re
benchmarking or running a production server you should pass --server
to JRuby to use the optimizing JVM. We’re generally about on par with
1.9…faster at some things and slower at others.
I would like to point out that the set of libraries available may be
quite different. Many Ruby-libraries use native c-code and are
unavailable in JRuby.
Almost all libraries that require C code have equivalents in Java that
can be called directly from Ruby. In many cases, we’ve even ported the
C code or wrapped those libraries so that the gem versions will work
(like, Hpricot, Mongrel, etc). Many C libraries can also be called
directly from JRuby with FFI. In general, you probably have access to
more libraries from JRuby because you’ve got Ruby libs, Java libs,
and any C libs you can call with FFI.
Another point is that operating-system-functionality is not really
available in Java beyond what can be commonly implemented on
different platforms supported by Java. So they are not easily accessed
in JRuby either. If such stuff is needed, native Ruby is better.
I have even used native Ruby to add Windows- and Linux-specific
functionalities for accessing OS-features needed and hidden in Java
from a Java software.
We’ve done a lot of work to implement OS functionality that doesn’t
normally exist in Java (and isn’t planned for addition). Things like
FFI for programmatically calling C libraries, POSIX filesystem
functions, UNIX sockets, and more. We’ve worked very hard to make as
much OS-level code work well on JRuby as possible.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs