Re: after_fork and redis

[Ben Somers <somers.ben@gmail.com>]

>> When I don't do this, each worker/pid seems to have their own redis
>> instance.  So, why is this needed?  Here's the logs of me printing out
>> $redis.client.inspect when both $redis = Redis.new in the after_fork
>> and just $redis = Redis.new in the environment.rb.

Checked through the redis.rb source a little bit, and I believe it's
got code specifically to avoid opening the connection until it's
needed, to prevent some shared connection problems
(https://github.com/redis/redis-rb/commit/d1bc88f85bc9bfbb7aabdfc2700bf4b30c0b0115).
You probably aren't making actual use of the connection until after
app startup, so that's why things are working so far for you. It's still
a good idea to initialize Redis in the after_fork, though, because if
something in your app's startup or initializer code does wind up using
that redis connection, you'd still get the shared connection problem.

> Sharing stream sockets across processes/threads is nearly
> always a bad idea: data streams become interleaved and impossible to
> separate in either direction.

"Nearly always a bad idea" is a bit of an understatement; the
interleaved data streams tend to create catastrophic errors, things
like users unable to log in or (god forbid) logging into other
people's sessions. And they usually manifest as race conditions, so
they're hard to debug if you don't know what to look for.
_______________________________________________
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