This project is archived and is in readonly mode.

#2580 ✓stale
Ali Aslam

Urgent: Session drops in rails 2.3.2

Reported by Ali Aslam | April 29th, 2009 @ 03:34 PM | in 3.x

Hello, I've been using memcache as a session store. After updating to rails 2.3.2, I've started encountering site users' sessions being dropped. This affects only the servers where the new rails is deployed. These session dropouts are intermittent and seem to increase with the number of requests to the rails application. This only occurs in production and works fine in development and test environments (using active_record as a session store in these envs). We're using the following setup in production: Apache 2.2.6 with Phusion Passenger 2.1.3 (also tried with passenger 2.2.2 but to no avail)

This is how I'm setting up memcache session store in production.rb:


# MEMCACHED_SERVERS holds array of memcached servers ips (total 3)
MEMCACHED_OPTIONS = {:namespace => "myapp-#{RAILS_ENV}"}
CACHE = MemCache.new MEMCACHED_SERVERS, MEMCACHED_OPTIONS
config.action_controller.session_store = :mem_cache_store
config.action_controller.session = {:cache => CACHE}

I've tried looking through the rails/rack codebase, but haven't figured out why this is happening.

It would really help if someone can look into this and at the least, inform me whether this is a rails 2.3.2 bug or something on my end. Thanks, Ali

Comments and changes to this ticket

  • Andy Watts

    Andy Watts October 14th, 2009 @ 09:58 PM

    I've seen similar behavior.
    My favorite candidate servers sharing a common socket to memcache.
    http://www.modrails.com/documentation/Users%20guide%20Apache.html#_...
    I think changing passenger to use the 'conservative' spawn method has fixed it for me, but not 100%.

  • Ben Marini

    Ben Marini October 16th, 2009 @ 06:21 AM

    Also remember that memcached is not a reliable session store as it removes old data when it runs out of space. From wikipedia:

    "Memcached's APIs provides a giant hash table distributed across multiple machines. When the table is full, subsequent inserts cause older data to be purged in least recently used (LRU) order."

    This would explain your situation, especially as you say the problem increases with the traffic.

  • Jeremy Kemper

    Jeremy Kemper May 4th, 2010 @ 06:48 PM

    • Milestone changed from 2.x to 3.x
  • Rohit Arondekar

    Rohit Arondekar October 14th, 2010 @ 11:02 AM

    • State changed from “new” to “stale”
    • Importance changed from “” to “”

    Marking ticket as stale. If this is still an issue please leave a comment with suggested changes, creating a patch with tests, rebasing an existing patch or just confirming the issue on a latest release or master/branches.

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

<h2 style="font-size: 14px">Tickets have moved to Github</h2>

The new ticket tracker is available at <a href="https://github.com/rails/rails/issues">https://github.com/rails/rails/issues</a>

Pages