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
_______________________________________________
Mongrel-users mailing list
Mongrel-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-users