On Thu, Jan 7, 2010 at 11:31 AM, Iñaki Baz Castillo <[email protected]> wrote: > El Jueves, 7 de Enero de 2010, Michael Guterl escribió: >> Our Rails app has started raising exceptions (caught by hoptoad >> thankfully) and I can only imagine they're related to unicorn. I only >> think the errors are occurring on the request after we deploy, which >> upgrades the Unicorn process. I say this because the errors are >> coming from many different actions, but I haven't been able to >> reproduce. > > Let me explain a problem I had with Sequel and Unicorn (already solved), > perhaps it's related: > > > I load Sequel database toolkit in the master process so it generates its own > threads pool. > Then Unicorn forks into workers but each worker uses the same instance of > Sequel database, this is, the same threads pool. > > This causes errors since some thread could be used by different processes at > the same time. > > The solution is simple: > > Don't set the Sequel instance in the master process, instead do it in each > worker ("after_fork" block in unicorn config file). > > In this way each process has its own Sequel instance with its own threads > pool. > > Also, using Sequel thread pool makes no sense when using Unicorn as each > worker is single thread, so I gain some performance by setting > "single_threaded = true" in Sequel database configuration (no thread pool > stuff). > > Probably you are getting a similar issue due to ActiveRecord or any other > multithread library you load in the master process so the instance is shared > between all the workers. >
We currently disconnect from both databases in before_fork and re-establish the connection in after_fork. Here's our unicorn config: http://gist.github.com/271449 Maybe I should disable connection pooling? Best regards, Michael Guterl _______________________________________________ Unicorn mailing list - [email protected] http://rubyforge.org/mailman/listinfo/mongrel-unicorn Do not quote signatures (like this one) or top post when replying
