Ruby Daemons and Jruby - Alternative Options

Ruby daemons and JRuby - alternative options

Since you cannot fork in JRuby you are basically left with having to refactor your daemon code so that the daemon can be executed as a standard foreground application then create a separate daemon launcher that will run and background the daemon. You can look at spoon and also check this gist which uses spoon to create a more elaborate launcher. Also jruby-jsvc provides the glue to use jsvc with a JRuby daemon.

Alternative for spawning a process with 'fork' in jRuby?

I found out the solution for this. We can use the built-in library FFI in JRuby to 'simulate' the Process.fork in MRI.

# To mimic the Process.fork in MRI Ruby
module JRubyProcess
  require 'ffi'
  extend FFI::Library
  ffi_lib FFI::Library::LIBC
  attach_function :fork, [], :int
end

pid = JRubyProcess.fork do
  #internal_server.run
end

More details:

https://github.com/ffi/ffi

http://blog.headius.com/2008/10/ffi-for-ruby-now-available.html

How to pass Java options to Puma daemon?

As mentionned in this blog post, you can put the JVM options in JRUBY_OPTS environment variable.

In your case, you could set the variable before starting Puma daemon :

export JRUBY_OPTS="-J-Xss4096k -J-Xmx2048m"

You may also try configuring the JVM directly by setting JAVA_OPTS environment variable :

export JAVA_OPTS="-Xss4096k -Xmx2048m"

Also check how the puma daemon is started

cat /proc/<pid>/environ

Your environment is not propagated to the Puma daemon. You need to find out how Puma is started. It may be as an init.d service or an upstart service.

Update:

It seems you can set your environment with rbenv-vars.

Create a .rbenv-vars file in your Rails project with the following

JAVA_OPTS='-Xss4096k -Xmx2048m'

Then your environment should be propagated to the puma daemon.

Options for a server container framework for Ruby/JRuby

The most "rubyish" thing would be to use mongrel or webrick, but I don't think very many folks do that.

I think the most common thing is to use Rails or Sinatra, then package them using as a war file using warbler. At that point, anything that can host a war file can host the app.

There's a pretty good list here.

Where are logs for Daemons of my ruby script

If you pass in an options hash as the second argument to the Daemons.run command you can add :log_output as true. Like this:

Daemons.run('script/meeting_receiver.rb', log_output: true)

This will send output to a file titled meeting_receiver.output.

See this example more details.

What are some alternatives to using Tomcat for Jruby Rack apps?

Trinidad gem / Embedded Tomcat

If you dig deeper into the Trinidad gem page on Github there are links to the various Trinidad extension gems. There is a daemonizing gem specifically supplied for use in production here:

http://github.com/calavera/trinidad_daemon

If you execute the install script and answer a handful of simple questions, it generates a tailored init script for your Ubuntu or OS X machine. That's pretty much all you need.

There are also example init scripts in the wiki here:

http://github.com/calavera/trinidad_daemon_extension/wiki/init.d-scripts

Note that for use in the Rails.threadsafe! mode, both min and max JRuby runtimes are set to 1 in your trinidad.yml configuration file.

I have it working on Ubuntu with an Nginx frontend, and it's working very nicely.

So yes, this means that you use the command line to stop and start the application server, but the init script will also be called automatically on system startup. The wiki also includes some Capistrano deploy script examples, so you can even have the server stop and start from your own machine.

Note: There are two daemon extensions. The one I have linked to is the new one, which uses a better daemonizing library.

GlassFish gem

You're right, the GlassFish gem isn't getting so much love right now, but I daresay things will improve. There are a couple of issues running it with JRuby 1.5+ because the gem didn't keep up with changes in JRuby, however I wrote about how to work around the issues here: http://www.scottlowe.eu/deploying-rails-3-with-jruby-daemonized-glass

Since writing that GlassFish post, Trinidad has gained the power to be dependably daemonized, so it's probably the smoother path to take today.

Something like PPerl for Ruby?

Have you looked at using nailgun? It sets up a background JVM process that your scripts execute in. That way you can use jruby w/o incurring the JVM startup time you would normally get with each script run.

---

Related Topics