Re: [jruby-user] Anything wrong with shelling out to jruby?

Ted -

That text mentions Nailgun; is Nailgun use still supported/recommended?  I thought no.

Thanks,
Keith

> On Mar 17, 2015, at 9:10 AM, Ted Han <[email protected]> wrote:
> 
> There's a section about this in the jruby wiki: https://github.com/jruby/jruby/wiki/Improving-startup-time#running-sub-rubies-in-the-same-jvm <https://github.com/jruby/jruby/wiki/Improving-startup-time#running-sub-rubies-in-the-same-jvm>
> 
> On Tue, Mar 17, 2015 at 9:07 AM, Keith Bennett <[email protected] <mailto:[email protected]>> wrote:
> I don’t know of any problems shelling out to JRuby, but it will require the memory and startup time of starting a whole new JVM for each time you do.  I would not be comforted by the fact that the OS might save your first JVM’s RAM to disk and restore it later; that would take time.  Is speed not important in your case?
> 
> If I were you, I’d look at minimum to shelling out once rather than a dozen times.  Why do you want to shell out so many times?
> 
> Also, your script looks like it shells out only once, no?
> 
> - Keith
> 
> > On Mar 16, 2015, at 6:45 PM, John Joseph Bachir <[email protected] <mailto:[email protected]>> wrote:
> >
> > I have an application where I would like to shell out to jruby. A very simple script that essentially does this a dozen times serially:
> >
> > begin
> >   `rails runner scripts/foo.rb`
> > rescue
> >   # .. report error
> > end
> >
> > I remember hearing about problems invoking jruby from jruby. Some initial basic tests in my dev environment don't show any problems.
> >
> > My guess at what the problem is: if jruby is configured to take an application's worth of RAM (say 512M), then the small out script will take that and then each individual sub process will take that as well.
> >
> > I wonder if in practice this won't matter much, because the OS will move most of the outer instance's memory into VM and just keep it there?
> >
> > Thanks for any insights or pointers to other info about this!
> >
> > John
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
> 
>     http://xircles.codehaus.org/manage_email <http://xircles.codehaus.org/manage_email>
> 
> 
>