#2644 Memcache session store + litespeed (and i think passenger) - Ruby on Rails

Type	To find
responsible:me	tickets assigned to you
tagged:"@high"	tickets tagged @high
milestone:next	tickets in the upcoming milestone
state:invalid	tickets with the state invalid
created:"last week"	tickets created last week
sort:number, importance, updated	tickets sorted by #, importance or updated
Combine keywords for powerful searching.
Use advanced searching »

This project is archived and is in readonly mode.

#2644 ✓stale

Memcache session store + litespeed (and i think passenger)

Reported by jerrett | May 14th, 2009 @ 02:22 AM | in 2.x

Using litespeed (and from searching the internets, it looks like passenger does the same thing) forks the parent process to create children, the following check:

unless @pool.servers.any? { |s| s.alive? }
 raise "#{self} unable to find server during initialization."
end

causes it to connect to the servers right away, which then requires the connection to be killed before forking the child processes.

While this is solvable in code (In litespeed by modifying their built in RailsRunner.rb, and in Passenger by following the info in the link below), I believe the issue is avoidable by removing the alive check, or at least moving it somewhere that doesn't get fired as soon as you setup your memcache store in environment.rb.

MemCacheStore in ActiveSupport::Cache doesn't suffer the same problem, because it doesn't do the alive check after it creates the MemCache object, and MemCache doesn't connect until it has to.

http://www.modrails.com/documentation/Users%20guide.html#%5Fexample...

With Litespeed the "odd behavior" that I was experiencing was users getting other users sessions.

Comments and changes to this ticket

You flagged this item as spam.
jerrett May 14th, 2009 @ 02:23 AM
Ooops, link got mangled... Mod rails memcache conncetion sharing harmful
You flagged this item as spam.
jerrett May 14th, 2009 @ 02:25 AM
If there was a way to access the instance of Memcache used by the session store, this would be even easier to fix and could probably even be fixed by default by servers like litespeed and passenger... perhaps I missed something, but I couldn't find a way to access the Memcache instance
You flagged this item as spam.
Jon Jensen April 2nd, 2010 @ 11:21 PM
Yeah, confirmed this happens in passenger as well (rails 2.3.2 in my case). When you use the same memcache object for sessions and cache-money, not only do you get the fun session hijacking behavior described above, you also see stuff like Apple.find(123) => #<Orange:0x0000face>
You flagged this item as spam.
Aaron Gibralter April 4th, 2010 @ 01:56 AM
Anyone know if this is changing in Rails 3?
You flagged this item as spam.
Aaron Gibralter April 4th, 2010 @ 02:23 AM
- Tag set to “mem_cache_store”
Yup... still seems like it's there: http://github.com/rails/rails/blob/master/actionpack/lib/action_dis...
Jeremy Kemper May 4th, 2010 @ 06:48 PM
- Milestone changed from “2.x” to “3.x”
[bulk edit]
Rohit Arondekar October 9th, 2010 @ 04:18 AM
- Importance changed from “” to “”
Any updates here? This is still an issue?
You flagged this item as spam.
Aaron Gibralter October 9th, 2010 @ 05:27 PM
Hmm well now it doesn't seem like it's a Rails 3.0.x issue anymore; however, it's definitely still in Rails 2.3.x.

As for 3.0.x, the relevant code has been moved into Rack::Session::Memcache (http://github.com/rack/rack/blob/master/lib/rack/session/memcache.r....

There is still the problem that the session store opens a connection to memcached during the app initialization, thus causing problems for servers (like Passenger and Thin) that fork off copies of the app.
Rohit Arondekar October 14th, 2010 @ 10:29 AM
- State changed from “new” to “open”
- Milestone changed from “3.x” to “2.x”
- Importance changed from “” to “Low”
Can you write a patch with tests to solve this issue? Or try and debug it further? That would be super helpful! Also thanks for the quick reply! :)
You flagged this item as spam.
Aaron Gibralter October 14th, 2010 @ 02:20 PM
... Well is it desirable to check for the memcache servers during intialization? Or would it be ok for Rails to raise an exception on the first app request that tries to connect to memcache for session storage and fails? Alternatively, Rails could check that the servers are there but then temporarily close the connections until they're needed: @pool.servers.any? { |s| s.alive? && s.close }

But I'm wondering... maybe Rails should stop supporting MemCacheStore out-of-the box... I understand CookieStore and ActiveRecordStore as default options because they're based entirely within Rails. But there are so many other stores out there and Ruby gems that support them; e.g.:

http://github.com/mperham/dalli
http://github.com/jodosha/redis-store

Perhaps MemCacheStore should just be deprecated in favor of dalli?
Rohit Arondekar October 14th, 2010 @ 02:25 PM
Aaron, there is already a ticket open regarding dalli. Could you please review the patch and give feedback here: https://rails.lighthouseapp.com/projects/8994/tickets/5588-integrat...
Ryan Bigg October 19th, 2010 @ 08:31 AM
- Tag cleared.
Automatic cleanup of spam.
Ryan Bigg October 19th, 2010 @ 08:31 AM
Automatic cleanup of spam.
You flagged this item as spam.
Aaron Gibralter October 30th, 2010 @ 12:01 AM
Rohit, it doesn't seem like Mike's patch addresses the session store... I updated that ticket though to raise the possibility.

I think that if they do decide to use Dalli for a session store, they should make sure that this ticket's issue is addressed. I also think that in 3.x, the Rails built in memcache session store should be deprecated... I'm not really sure what to do about 2.3.x though...
Santiago Pastorino February 9th, 2011 @ 12:31 AM
This issue has been automatically marked as stale because it has not been commented on for at least three months.

The resources of the Rails core team are limited, and so we are asking for your help. If you can still reproduce this error on the 3-0-stable branch or on master, please reply with all of the information you have about it and add "[state:open]" to your comment. This will reopen the ticket for review. Likewise, if you feel that this is a very important feature for Rails to include, please reply with your explanation so we can consider it.

Thank you for all your contributions, and we hope you will understand this step to focus our efforts where they are most helpful.
Santiago Pastorino February 9th, 2011 @ 12:31 AM
- State changed from “open” to “stale”
You flagged this item as spam.
Aaron Gibralter February 14th, 2011 @ 02:37 PM
This has been moved into Rack::Session::Memcache: https://github.com/rack/rack/blob/master/lib/rack/session/memcache....

I think we can close it for Rails. I'll re-open on Rack's github issues page.
You flagged this item as spam.
bingbing March 26th, 2011 @ 02:10 AM
louis vuitton watches