From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS14383 205.234.109.0/24 X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,MSGID_FROM_MTA_HEADER, RP_MATCHES_RCVD shortcircuit=no autolearn=unavailable version=3.3.2 Path: news.gmane.org!not-for-mail From: =?iso-8859-1?q?I=F1aki_Baz_Castillo?= Newsgroups: gmane.comp.lang.ruby.unicorn.general Subject: Re: Confused classes Date: Sat, 6 Feb 2010 14:06:04 +0100 Message-ID: <201002061406.04172.ibc@aliax.net> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1265462562 26205 80.91.229.12 (6 Feb 2010 13:22:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 6 Feb 2010 13:22:42 +0000 (UTC) To: mongrel-unicorn@rubyforge.org Original-X-From: mongrel-unicorn-bounces@rubyforge.org Sat Feb 06 14:22:40 2010 Return-path: Envelope-to: gclrug-mongrel-unicorn@m.gmane.org X-Original-To: mongrel-unicorn@rubyforge.org Delivered-To: mongrel-unicorn@rubyforge.org User-Agent: KMail/1.12.2 (Linux/2.6.28-16-generic; KDE/4.3.2; x86_64; ; ) In-Reply-To: X-BeenThere: mongrel-unicorn@rubyforge.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: mongrel-unicorn-bounces@rubyforge.org Errors-To: mongrel-unicorn-bounces@rubyforge.org Xref: news.gmane.org gmane.comp.lang.ruby.unicorn.general:404 Archived-At: Received: from rubyforge.org ([205.234.109.19]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1NdkcR-0005G5-NF for gclrug-mongrel-unicorn@m.gmane.org; Sat, 06 Feb 2010 14:22:39 +0100 Received: from rubyforge.org (rubyforge.org [127.0.0.1]) by rubyforge.org (Postfix) with ESMTP id 3498118582DE; Sat, 6 Feb 2010 08:22:36 -0500 (EST) Received: from mail-ew0-f212.google.com (mail-ew0-f212.google.com [209.85.219.212]) by rubyforge.org (Postfix) with ESMTP id D90A818582D2 for ; Sat, 6 Feb 2010 08:06:10 -0500 (EST) Received: by ewy4 with SMTP id 4so490926ewy.7 for ; Sat, 06 Feb 2010 05:06:09 -0800 (PST) Received: by 10.213.49.140 with SMTP id v12mr3512105ebf.6.1265461569387; Sat, 06 Feb 2010 05:06:09 -0800 (PST) Received: from ibc-laptop.localnet ([212.230.46.89]) by mx.google.com with ESMTPS id 23sm7464048eya.11.2010.02.06.05.06.06 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 06 Feb 2010 05:06:07 -0800 (PST) El S=E1bado, 6 de Febrero de 2010, Warren Konkel escribi=F3: > I switched from mod_passenger to unicorn on a fairly high traffic site > and ran into a strange problem that forced me to move back to > mod_passenger... it seems as if classes would sometimes get mixed up > with each other. If I had two Rails models: > = > class Foo < ActiveRecord::Base; end > class Bar < ActiveRecord::Base; end > = > Normally Foo.inspect and Bar.inspect would return: > = > Foo(field1: integer, field2: integer) > Bar(field3: integer, field4: integer) > = > When things were "broken" within a process, sometimes I would see: > = > Foo(field3: integer, field4: integer) <--- note field3/field4 > actually belong to Bar, not Foo > = > And because of that, wacky errors would appear in my logs like: > = > Foo.find_by_field1(12345) --> not a method > Foo.create(:field1 =3D> 12345) --> column not found > = > I also noticed the problem with field serializing in ActiveRecord... give= n: > = > class Boz < ActiveRecord::Base > serialize :some_data > end > = > When processes were working correctly, Boz.find(1).some_data would > return an actual object (like a Hash). When things were broken, the > raw serialized string from the database would be returned... almost as > if the Boz class "forgot" that it's supposed to deserialize > "some_data". > = > Could it be that class attributes are somehow being co-mingled when > unicorn is starting up under high concurrency? Perhaps a mutex is > missing somewhere? IMHO all your Unicorn workers are sharing the same DB connection (the same = ActiveRecord instances) so the problem arises. Take a look to the configuration here: http://unicorn.bogomips.org/examples/unicorn.conf.rb You can see there how the ActiveRecord is disconnected at the beggining and = started for each worker later. -- = I=F1aki Baz Castillo _______________________________________________ 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