Re: how many Ruby 1.8 users left?
It's a repost, since my iPhone mail client sent garbage. Sorry about that. 2013/7/24 Eric Wong : > Hi all, just wondering how many users are still on Ruby 1.8. unicorn > still supports 1.8 for now, but going 1.9.3+ (or even 2.0.0+) will allow > us to kill some old code we've been keeping around... I still maintain an old internal Rails 2.3 app with no plans to upgrade. > On the other hand, I don't expect unicorn to change much and maybe they > can just use the old versions. Exactly. I'd be happy to have a faster/smaller Unicorn for my recent Ruby 1.9/2.0 apps. > Thanks for reading. Thanks for making Unicorn -- Jérémy Lecour : http://jeremy.wordpress.com - http://twitter.com/jlecour ___ Unicorn mailing list - mongrel-unicorn@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-unicorn Do not quote signatures (like this one) or top post when replying
Re: [PATCH] unicorn_forever: new executable to respawn masters
Jeremy Lecour wrote: > > This may be useful for daemontools and similar init replacements > > which behave badly when the master process is replaced during the > > normal SIGUSR2 && SIGQUIT routine. > > Does Monit fall into this category of tools? > > Each time I restart a master process I have an alert (change of pid) > which is fine but not necessary. I don't think so (but I'm not familiar with monit, either). Getting an alert is one thing, but the problem is the manager attempting to restart (and fail) because it thinks unicorn is dead (because it "escaped"). ___ Unicorn mailing list - mongrel-unicorn@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-unicorn Do not quote signatures (like this one) or top post when replying
Re: [PATCH] unicorn_forever: new executable to respawn masters
> This may be useful for daemontools and similar init replacements > which behave badly when the master process is replaced during the > normal SIGUSR2 && SIGQUIT routine. Does Monit fall into this category of tools? Each time I restart a master process I have an alert (change of pid) which is fine but not necessary. -- Jeremy ___ Unicorn mailing list - mongrel-unicorn@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-unicorn Do not quote signatures (like this one) or top post when replying
Re: Increassing timeouts
Troex Nevelin wrote: > On Jan 15, 2013, at 21:44 , Eric Wong wrote: > > But seriously, who will wait 120s for a website to load? > > I have similar situation, in my case it's admin interface so admin > knows that some operations need time to process and will wait. > > Right now I'm running two packs of Unicorn instances - one for quick > and one for long requests. But most of the time long request pool is > idling and eating memory. Cranking up the timeout will improve its chances of being swapped out. If memory usage of an infrequently used instance is a concern. > My question: is possible to change Unicorn timeout per request from > Rails app? Middleware hook could be ok too. (not sure if it's possible > as I think timeout is set in master). Right, it's currently not possible to influence the master. And I'm not convinced it's the right way to go, either. What I've done in the past is to put the client in a periodic refresh loop (meta refresh or whatever tag it was) and have it poll the app while it was waiting for a long-running job to finish. I think it was (or still is) a common thing... Btw, Rubyforge delayed this email by over 3 weeks? But then again you responded to a 6 month old thread %x ___ Unicorn mailing list - mongrel-unicorn@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-unicorn Do not quote signatures (like this one) or top post when replying
