merb wants a girlfriend named unicorn

[scottmotte]

Hi guys,

Any thoughts on why using unicorn to run merb would quickly load up
the merb app, close it down, then respawn and try again - and then
repeat that over and over again.

The config.ru file is the same I'd use for thin, and I'm on the latest
Merb 1.1 from wycats github.

#my config.ru
require 'merb-core'
Merb::Config.setup(:merb_root => ".", :environment => ENV['RACK_ENV'])
Merb.environment = Merb::Config[:environment]
Merb.root = Merb::Config[:merb_root]
Merb::BootLoader.run

use Merb::Rack::Static, Merb.dir_for(:public)
run Merb::Rack::Application.new

# if you want to try unicorn yourself.
The command to setup and run unicorn is:
sudo gem install unicorn
cd yourapp
unicorn # alternatively to try on a rails app it's 'unicorn_rails'

I'm asking this in the unicorn forum too.

[Nicholas Orr]

I had a go at running merb via unicorn and had the same experience.

My guess was that because merb does it's own bootstrap stuff then
launches (forks?) thin/mongrel - this is where running with unicorn
falls over.

As you can see in the unicorn_rails start script it is very different
from the unicorn script and basically satisfies rails way of doing
things.

One thing I didn't try was starting with a working passenger config.ru
- that may have resulted in a working solution...

A goal of 1.2 might be have merb behave more rack like so one could
use rackup - then merb could slot into everything (middlewares, rack
stack) else rather than the current situation that everything can slot
into merb...

Nick

[Yehuda Katz]

I would be in favor of removing the Merb bootstrap stuff in favor of unicorn, which is basically the same code but made more generic.

We could do that for 1.2 for sure.

-- Yehuda

--
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325

[Pavel Kunc]

Unicorn support could come earlier than 1.2. I'd like to bundle it
with the 1.1 if possible because it would allow out of box 1.9.1
experience. I'd also made unicorn as default adapter. So I think we
can try for now to write unicorn adapter and just plug unicorn to merb
the same way as other servers.

We can than decide what to do with the bootstraping.

Pavel

[Matt Aimonetti]

I think that making unicorn the default adapter is not a very good idea.
It still has lots of bugs and should be handled with caution.

I also think that it might not be worth delaying 1.1 to add unicorn support.

- Matt

[Yehuda Katz]

I agree

[Ezra Zygmuntowicz]

Unicorn is by far less buggy then the current forking/master/worker
stuff in merb. I say go for unicorn support.

-Ezra

Ezra Zygmuntowicz
e...@engineyard.com

[Matt Aimonetti]

Whatever, changing such a critical aspect of Merb right before a major release doesn't seem wise at all.
My suggestion: release 1.1, and play with unicorn in a separate branch/trunk. Once it's ready and you know it's reliable and better than the existing solution, then push a new release.

- Matt

[Nicholas Orr]

Yeah I'd aim for 1.2 and getting rid of the bootstrap stuff.

Merb doesn't need to handle forking master/worker stuff anymore...
There are tools available that can do this.

Imho it make sense to make merb work with rack up like sinatra. That
way if someone else comes up with a new way to run rack apps merb
works out of the box, rather than having to implement special support
for in merb for the new tool.

Nick

[Matt Aimonetti]

+1 Passenger 3 is also coming up with lots of goodies.

- Matt

[Pavel Kunc]

Hi all, good to see you on mailing list again.

This really amused me:

"I also think that it might not be worth delaying 1.1 to add unicorn
support."

Good joke. The 1.1 can't be significantly delayed by adding unicorn
adapter. Because it already has delay about a year or so. Really, the
1.1 promised many things and almost none of it was delivered. One of
the crucial part of 1.1 is 1.9.1 support. Tell me how you want to
provide out of box support on 1.9.1 if you defaults to Mongrel which
doesn't run on the 1.9.1?

The idea of Merb adapters is that user can use server he wants by just
using the switch. Latest patch in 1.1 even allows you to set your
adapter in the init so you can use thin and don't need to type merb -a
thin all the time.

Current 1.1.0.pre version is ready to ship to the public for testing
and once Martin solve last issue with merb-stack app, we're going to
push it to Gemcutter. Developers and users are frustrated with lack of
production release, bugfixes, and communication.

On the removing whole master/worker stuff and maybe also the class
reloading which can be now solved outside Merb I totally agree with
Nicholas. My opinion is that it really shouldn't go to the 1.2. It
should not go to any of 1.x versions because it breaks the API. And
one thing we tried hard to keep was API during work on 1.1.0.pre. We
wanted to remove many things from Merb but because of spec10 must pass
for 1.x we can't.

So for me it really is what you want to do with Merb? Because what
would be the best IMHO, is to release 1.1.0. as we have it now with
Unicorn. To provide good working release on 1.9.1 and compatible with
spec10. And start working on Merb 2.0 (and yes I never liked statement
Merb 2 == Rails 3). In Merb 2.0 we can easily break API, we can drop
spec10 and use current spec as frozen API state. Than we can remove
bootstraping, change router, bring merb much closer to Rack and all
integrate all the cool stuff which just emerge lately.

If all this sounds a bit angry, it is. And also it's the point of view
of someone who don't need/want to migrate to R3.

Pavel

On Nov 6, 10:23 pm, Matt Aimonetti <mattaimone...@gmail.com> wrote:
> +1 Passenger 3 is also coming up with lots of goodies.
>
> - Matt
>
>
>
> On Fri, Nov 6, 2009 at 1:55 PM, Nicholas Orr <nicholas....@zxgen.net> wrote:
>
> > Yeah I'd aim for 1.2 and getting rid of the bootstrap stuff.
>
> > Merb doesn't need to handle forking master/worker stuff anymore...
> > There are tools available that can do this.
>
> > Imho it make sense to make merb work with rack up like sinatra. That
> > way if someone else comes up with a new way to run rack apps merb
> > works out of the box, rather than having to implement special support
> > for in merb for the new tool.
>
> > Nick
>

> > On Sat, Nov 7, 2009 at 5:48 AM, Matt Aimonetti <mattaimone...@gmail.com>

> > wrote:
> > > Whatever, changing such a critical aspect of Merb right before a major
> > > release doesn't seem wise at all.
> > > My suggestion: release 1.1, and play with unicorn in a separate
> > > branch/trunk. Once it's ready and you know it's reliable and better than
> > the
> > > existing solution, then push a new release.
>
> > > - Matt
>

> > > On Fri, Nov 6, 2009 at 10:40 AM, Ezra Zygmuntowicz <ezmob...@gmail.com>

> > > wrote:
>
> > >>        Unicorn is by far less buggy then the current
> > forking/master/worker
> > >> stuff in merb. I say go for unicorn support.
>
> > >> -Ezra
>
> > >> On Nov 6, 2009, at 10:32 AM, Yehuda Katz wrote:
>
> > >> > I agree
>
> > >> > On Fri, Nov 6, 2009 at 10:22 AM, Matt Aimonetti <

> > mattaimone...@gmail.com

> > >> > > wrote:
> > >> > I think that making unicorn the default adapter is not a very good
> > >> > idea.
> > >> > It still has lots of bugs and should be handled with caution.
>
> > >> > I also think that it might not be worth delaying 1.1 to add unicorn
> > >> > support.
>
> > >> > - Matt
>

> > >> > On Fri, Nov 6, 2009 at 3:56 AM, Pavel Kunc <pavel.k...@gmail.com>

[Chris]

Never been a fan of Merb 2 == Rails 3 either. FWIW, not a fan of the rails merger at all.

2009/11/7 Pavel Kunc <pavel...@gmail.com>

[Matthew Beale]

Yeah please. Changing the server setup right in the middle of 1.0's
releease was a complete mess. Let's not do that again :-)

--
Matthew Beale :: 607 227 0871
Resume & Portfolio @ http://madhatted.com

[Nicholas Orr]

I dont think it is angry, u've raised a good point re spec10.
What you have laid out makes total sense and I'd love to see that as
the direction to go, thanks for paying attention to the details ;)

Nicholas

[botanicus]

Have you bother to read what Pavel wrote about the Ruby 1.9 support? I
think this is pretty reasonable argument.

On Nov 7, 1:44 pm, Matthew Beale <mixo...@synitech.com> wrote:
> Yeah please.  Changing the server setup right in the middle of 1.0's
> releease was a complete mess.  Let's not do that again :-)
>
> --
> Matthew Beale :: 607 227 0871

> Resume & Portfolio @http://madhatted.com

>
>
>
> On Fri, 2009-11-06 at 10:48 -0800, Matt Aimonetti wrote:
> > Whatever, changing such a critical aspect of Merb right before a major
> > release doesn't seem wise at all.
> > My suggestion: release 1.1, and play with unicorn in a separate
> > branch/trunk. Once it's ready and you know it's reliable and better
> > than the existing solution, then push a new release.
>
> > - Matt
>
> > On Fri, Nov 6, 2009 at 10:40 AM, Ezra Zygmuntowicz
> > <ezmob...@gmail.com> wrote:
>
> >                Unicorn is by far less buggy then the current
> >         forking/master/worker
> >         stuff in merb. I say go for unicorn support.
>
> >         -Ezra
>
> >         On Nov 6, 2009, at 10:32 AM, Yehuda Katz wrote:
>
> >         > I agree
>
> >         > On Fri, Nov 6, 2009 at 10:22 AM, Matt Aimonetti

> >         <mattaimone...@gmail.com

> >         > > wrote:
> >         > I think that making unicorn the default adapter is not a
> >         very good
> >         > idea.
> >         > It still has lots of bugs and should be handled with
> >         caution.
>
> >         > I also think that it might not be worth delaying 1.1 to add
> >         unicorn
> >         > support.
>
> >         > - Matt
>
> >         > On Fri, Nov 6, 2009 at 3:56 AM, Pavel Kunc

> >         <pavel.k...@gmail.com>

[Matt Aimonetti]

For the record, I have a mongrel fork that's 1.9 compatible and patches were provided to Evan, however it looks like Twitter might switch to passenger and I don't know if they will maintain mongrel much longer.

- Matt

[Pavel Kunc]

Yep Matt, that's the biggest problem I see with the Mongrel. The
development will stop rather sooner than later especially with
alternatives which are alive such as Unicorn or Passenger or Thin &
friends.

Pavel

[dreamcat4]

On Nov 6, 1:51 am, scottmotte <sc...@scottmotte.com> wrote:
> Hi guys,
>
> Any thoughts on why using unicorn to run merb would quickly load up
> the merb app, close it down, then respawn and try again - and then
> repeat that over and over again.

Hi,
Adam over at Chef / Opscode has come up with this pretty awesome
config.ru file for chef. Works on chef+merb 1.0.15. Therefore its, by
no means guaranteed to work for anybody else. But you are welcome to
try it. Notice how we set :fork_for_class_load => false to prevent the
merb bootstrap from forking.

config.ru:
require 'rubygems'
require 'merb-core'
require 'chef'

Chef::Config.from_file(File.join("/etc", "chef", "server.rb"))

Merb::Config.setup(:merb_root => File.expand_path(File.dirname
(__FILE__)),
:environment => ENV['RACK_ENV'] || "development",
:fork_for_class_load => false,
:init_file => File.dirname(__FILE__) / "config/
init.rb")

Merb.environment = Merb::Config[:environment]
Merb.root = Merb::Config[:merb_root]
Merb::BootLoader.run

# Uncomment if your app is mounted at a suburi
#if prefix = ::Merb::Config[:path_prefix]
# use Merb::Rack::PathPrefix, prefix
#end

# comment this out if you are running merb behind a load balancer
# that serves static files
# use Merb::Rack::Static, Merb.dir_for(:public)

run Merb::Rack::Application.new
EOF<<

Then create a unicorn.config and execute unicorn in the same folder as
the above config.ru.
Your unicorn.config config can contain a 'working_directory'
configuration setting that points to the real directory for the merb
app.

unicorn.config:
worker_processes <%= @worker_processes %>
working_directory "<%= @m_path %>"
listen <%= @port %>
preload_app false
EOF<<


NOTICE:
You might get some session / cookie rack error
You might get any other rack/merb errors
So be warned !


dreamcat4
drea...@gmail.com

[dreamcat four]

And here's a rackup file for running a merb slice under unicorn. It
was helped a lot by the following blog post:
http://msmvps.com/blogs/nuoyan/archive/2009/05/21/making-a-executable-standalone-merb-slice-gem.aspx

config.ru:
require 'rubygems'
require 'merb-core'

# Dir.chdir("/pathto/merb-slice")

Merb::Config.setup(:merb_root => File.expand_path(File.dirname(__FILE__)),

:environment => ENV['RACK_ENV'] || "development",
:fork_for_class_load => false,

:init_file => File.dirname(__FILE__) / "config/init.rb")

Merb.environment = Merb::Config[:environment]
Merb.root = Merb::Config[:merb_root]

# Uncomment if your app is mounted at a suburi
#if prefix = ::Merb::Config[:path_prefix]
# use Merb::Rack::PathPrefix, prefix
#end

# comment this out if you are running merb behind a load balancer
# that serves static files
# use Merb::Rack::Static, Merb.dir_for(:public)

use Merb::Rack::Static, Merb.root+"/public"

require 'merb-slices'
slice_name = "chef-server-webui"

if File.exists?(slice_file = File.join(Merb.root, 'lib', "#{slice_name}.rb"))
Merb::BootLoader.before_app_loads do
$SLICE_MODULE = Merb::Slices.filename2module(slice_file)
require slice_file
end
Merb::BootLoader.after_app_loads do
# See Merb::Slices::ModuleMixin - $SLICE_MODULE is used as a flag
Merb::Router.prepare do
slice($SLICE_MODULE)
slice_id = slice_name.gsub('-', '_').to_sym
slice_routes = Merb::Slices.named_routes[slice_id] || {}

# Setup a / root path matching route - try several defaults
route = slice_routes[:home] || slice_routes[:index]
if route
params = route.params.inject({}) do |hsh,(k,v)|
hsh[k] = v.gsub("\"", '') if k == :controller || k == :action
hsh
end
match('/').to(params)
else
match('/').to(:controller => 'merb_slices', :action => 'index')
end
end
end
else
puts "No slice found (expected: #{slice_name})"
exit
end

class MerbSlices < Merb::Controller

def index
html = "<h1>#{slice.name}</h1><p>#{slice.description}</p>"
html << "<h2>Routes</h2><ul>"
sorted_names = slice.named_routes.keys.map { |k| [k.to_s, k]
}.sort_by { |pair| pair.first }
sorted_names.each do |_, name|
if name != :default && (route = slice.named_routes[name])
if name == :index
html << %Q[<li><a href="#{url(route.name)}" title="visit
#{name}">#{name}: #{route.inspect}</a></li>]
else
html << %Q[<li>#{name}: #{route.inspect}</li>]
end
end
end
html << "</ul>"
html
end

private

def slice
@slice ||= Merb::Slices.slices.first
end

end

Merb::BootLoader.run
run Merb::Rack::Application.new


dreamcat4
drea...@gmail.com