[Mongrel] Sharing a mongrel cluster in a multi-url environment

John Almberg jalmberg at identry.com
Thu Jan 29 10:33:24 EST 2009


On Jan 29, 2009, at 9:32 AM, John Almberg wrote:

>
> On Jan 28, 2009, at 5:45 PM, David Vrensk wrote:
>
>> I don't think this is mongrel's fault, but it's interesting  
>> nonetheless.
>>
>> Could you have apache log the incoming cookie value to shed some  
>> more light on what happens?  I believe that the cookie you see is  
>> not the cookie that the client sends, but a new cookie that Rails  
>> generates when it cannot find the cookie from the request in its  
>> current db.
>>
>> My theory (aka wild guess) is that Rails picks up the cookie  
>> before you change/set the database connection.  Like this:
>>
>> User1 requests the login page.
>> Rails connects to db1 and renders the page.
>> User1 logs in and is given a cookie, and session data is stored in  
>> db1.
>> User1 does something and all is good.
>> User2 requests the login page.
>> Rails connects to db2 and renders.
>> User1 requests a new page.
>> Rails is connected to db2 and fails to find the cookie.
>> Rails connects to db1 and redirects user.
>>
>> Now, this isn't exactly what's happening in your logs, but add the  
>> fact that the different requests are being handled by different  
>> mongrels, each with their Rails stacks and db connections, and you  
>> have a fine mess.
>
> H'mmm. This is an interesting idea. I will do some testing to see  
> if this is the problem

Okay, here is what I did.

1. I retested the configuration that used a separate mongrel instance  
(fired up from the command line) for each virtual host. No problem.  
[2 virtual hosts, 2 mongrels, 1 rails app, 2 databases]

2. I connected the two Apache virtual hosts back to the  
mongrel_cluster (of 1 mongrel). The problem re-appeared. [2 virtual  
hosts, 1 mongrel cluster, 1 rails app, 2 databases]

3. I changed the X_CLIENT_ID header in example2.com so it matched the  
client_id in example1.com. This means that both domains connected to  
the same database, without changing anything else. The problem  
disappeared. [2 virtual hosts, 1 mongrel cluster, 1 rails app, 1  
database]

This test seems to confirm that the problem is in the database  
switching.

But scenario #1 also had the database switching and worked fine. This  
makes me think that a mongrel instance has some sort of persistent  
connection to the rails application, and the database that is 'active'.

Is this true? Is the problem seen in scenario #2 caused by this  
persistent connection being forced over to different URL and  
different database?

-- John




More information about the Mongrel-users mailing list