Problem/Motivation
Session support for memcache has been partially ported to Drupal 7, however it has not had enough testing to be considered stable, and there are core bugs with session support (particularly mixed http/https sessions) which are not correctly handled by memcache either (and likely won't be until the core bugs are fixed).
Proposed resolution
To help memcache session support in Drupal 7, please test the memcache-session.inc and open issues for any specific bugs found, linking to them from here, if an existing bug report does not already exist.
Remaining tasks
#1785744: Memcache Session Handler does not initialize user timezone
#1908348: Session backend fails to update user access time
#577214: $user->session_data_present_at_load is never set in sess_write()
#1908358: Incorrect require_once path in memcache-session.inc
#1984226: Session handler uses D6 hook_user() instead of D7 hook_user_update()
#973228: Port D7 core lazy session writing
#1396358: After installing memcache, getting mixed session problem - http & https
Comment | File | Size | Author |
---|---|---|---|
#44 | memcache-anon-session-656838.patch | 1.08 KB | Firemyst |
#41 | memcache-anon-session-656838.patch | 572 bytes | Firemyst |
#39 | memcache-no-session.patch | 522 bytes | igor.ro |
#38 | diff.patch | 884 bytes | jimyhuang |
#24 | memcache-session-656838-24.patch | 1.38 KB | quicksketch |
Comments
Comment #1
litwol CreditAttribution: litwol commentedSome session_save_session were not renamed to drupal_save_session.
Comment #2
chx CreditAttribution: chx commentedMostly works. The tests , copied from core session tests do not pass. Other tests now do.
Comment #3
Jeremy CreditAttribution: Jeremy commentedI've merged what you've implemented so far so as to not lose this effort, after confirming that there were no regressions to the core memcache functionality. Leaving open until all tests pass.
Comment #4
chx CreditAttribution: chx commentedThe challenge here is that we need to be able to query by both ssid and sid. I think storing (ssid, sid) pairs would help and then you need two requests when ssid comes into play but that's not a biggie.
Comment #5
Jeremy CreditAttribution: Jeremy commentedMultiget is now fully functional in this module with both the PECL memcache and PECL memcached plugins, so multiple gets is not a problem.
Comment #6
chx CreditAttribution: chx commentedbut this multiple get is that if you have a ssid you request the sid and then request the value of sid. Ie. the second get depends on the first.
Comment #7
robertDouglass CreditAttribution: robertDouglass commentedWhat's the status of this? What are the flaws or deficiencies of the session handling in the current d7 memcache module?
Comment #8
chx CreditAttribution: chx commentedSee above. Someone needs to write code so that if the request is per ssid then we can first retrieve the sid and then from the sid then the record. Or so I think.
Comment #9
sylv3st3r CreditAttribution: sylv3st3r commentedAny update on this? I believe we already have code freeze on drupal sessions
Comment #10
bblake CreditAttribution: bblake commentedI've got a patch that will allow for the session handling to work ( minus the ssid versus sid pieces ).
Comment #11
Jeremy CreditAttribution: Jeremy commentedThanks bblake, patch committed!
http://drupal.org/cvs?commit=473770
We're still needing to fix the ssid/sid issue, leaving status on this issue as 'needs work'.
Comment #12
ogi CreditAttribution: ogi commentedsubscribe
Comment #13
_-. CreditAttribution: _-. commentedsub
Comment #14
_-. CreditAttribution: _-. commentedwith this patch in place, what's the right way to implement it?
if in settings.php,
$conf['session_inc'] = './sites/all/modules/memcache/memcache-session.inc';
on page load i see,
Notice: Undefined property: stdClass::$session in _drupal_session_read() (line 56 of /nas/srv/d7/006/sites/all/modules/memcache/memcache-session.inc).
do i need to include instead?
Comment #15
pillarsdotnet CreditAttribution: pillarsdotnet commentedI think you need to do both the include and the $conf setting.
Comment #17
catchComment #18
catchI made an interim commit to remove an outdated cache constant from the test, there's still one failure here that looks genuine, let alone http vs. https sessions being broken in core too of course.
Comment #19
BerdirWhat failure exactly? I've run the tests this week and everything was green...
Comment #20
catchThe fail I get is "Session data persists through browser close." line 98 of memcache-session.test
I didn't debug this though. Interesting if that test passes for you...
Comment #21
BerdirYep, the tests seemed to work for me however, when actually switching memcache-session.inc on, I got the same error as reported in #14, probably just because memcache expected a session key to exist which didn't, so maybe a quick check there would make sense.
I left it on and everything worked just fine. On the next day, I did some unrelated, simple load tests and it suddenly stopped working *completely*. Plain simply no sessions at all, e.g. filling out the login form redirected you to the user page but then you were logged out again. Reproducable, for everyone in the room. Had to no time to investigate as others were working on the site so I switched it back off.
Not sure if it is still recommended to have a separate memcache instance for the sessions and memcache was rather full (still working on fine-tuning the whole setup) but even then, new cache_set()'s shouldn't simply be ignored?
Comment #22
catchSession should be in a separate bin - you want headroom so that sessions don't get evicted before they expire naturally.
However I agree that brand new sets shouldn't be affected by this, would probably be good to rule it out though.
Comment #23
hswong3i CreditAttribution: hswong3i commentedD7 drupal_anonymous_user() is updated so we also need to renew _memcache_session_user_load() with new syntax (http://api.drupal.org/api/drupal/includes--bootstrap.inc/function/drupal...).
Patch via memcache-7.x-1.x, tested with drupal-7.9 and Memcache v3.0.4.
Comment #24
quicksketchThanks @hswong3i for the patch in #23. I found a few issues with the approach however, specifically for me drupal_set_message() was not working when the user was anonymous. That's because the patch was setting $user->session = '' if the $user->uid was 0. In most situations that's fine, but in the case of messages, they're currently broken (even with the patch in #23).
This patch makes safe changes by adjusting for the changes in drupal_anonymous_user(). If you look at the current documentation, you can see that passing in a $session is absolutely silly, because that function doesn't take any arguments at all. This patch simply provides the same functionality as D6 by adjusting for the change in the API. This patch in my testing solves the notice mentioned above and also work with anonymous user messages.
Comment #25
estepix CreditAttribution: estepix commentedNot sure if this helps but I was getting the error:
Notice: Undefined property: stdClass::$session in _drupal_session_read() (line 56 of /var/www/www.mysite.com/sites/all/modules/contrib/memcache/memcache-session.inc).
Right after logging out of Drupal. Using:
Drupal core 7.10
Memcache 7.x-1.x-dev
This is probably not a good solution but I fixed it by placing this:
if (!isset($user->session)) {
$user->session = '';
}
Right before:
return $user->session;
In function _drupal_session_read($key)
Comment #26
jaroslaw.kaminski CreditAttribution: jaroslaw.kaminski commentedIs exists any roadmap for porting this to D7? I need to move sessions from database and this solution will be great for me.
Comment #27
catchI've committed #24 to 7.x-1.x, moving back to active since there's more to do here.
@jaroslaw.kaminski there are outstanding critical/major bugs in Drupal core's session handling in D7 that make it trickier to port the memcache version than it otherwise would be (since the actual desired behaviour is not set yet). As well as this, I have no time to spend on testing/fixing the session handling in D7 for memcache. I will however try to review/commit patches if they're posted here, and testing/reviewing existing patches in the queue, or posting bug reports with steps to reproduce if there's not an existing issue is very welcome.
Comment #28
sinn CreditAttribution: sinn commentedI use memcache-session.inc and it works fine for me. Do you know any problems with memcache sessions? I need sessions for production site but I don't know if it can be usable. In readme.txt is written that it is dev version only. I can fix memcache-sessions but don't know about problems with it.
Comment #29
BerdirNobody knows how stable this is, that's basically the reason for this issue to be still open and the code to be in the unstable directory.
So, test it and report back with your findings :)
Comment #30
ywarnier CreditAttribution: ywarnier commentedMy own "survey" answer: I use the memcache-session.inc from unstable on several D7 site and it works fine until now. None of them is really in production yet, but as far as I can tell it doesn't loose any session so far (a dozen different users, sometimes simultaneous).
Comment #31
rogical CreditAttribution: rogical commentedI think We can commit it first, but stated which needs more testing, Then more people can test.
Comment #32
wedge CreditAttribution: wedge commentedI'm having an issue with this. If I use user_save to change the current user's name it will not update the current session.
And then later in the session check $user->name
It works fine with the standard db session handling. Any ideas?
Comment #33
thedavidmeister CreditAttribution: thedavidmeister commentedHey, can somebody link in the "multiple core issues" that chx is referencing so we can see/track the status of those in this thread?
Comment #34
chx CreditAttribution: chx commentedyou meant catch in #27
Comment #35
thedavidmeister CreditAttribution: thedavidmeister commentedI didn't actually, this is C&P from the OP:
But yes, including catch's references would be great too :)
Comment #36
quicksketchI've had great success with the current memcache-session.inc file. I've been running http://webform.com for months using the memcache session handler with no loss of sessions, user login/logout works fine.
A few things I did that may be helping prevent any problems:
- I set up an entirely different memcache daemon/port just for sessions.
- I don't allow HTTP session cookies at all, all sessions are over HTTPS by setting
session.cookie_secure = 1
in php.ini.So unfortunately I don't know if my situation helps qualify the session handler as stable since I've worked to separate session handling from the rest of the site.
I did discover a bug with timezone handling (apparently in D7, the session initialization is responsible for timezones): #1785744: Memcache Session Handler does not initialize user timezone
Comment #37
pillarsdotnet CreditAttribution: pillarsdotnet commented@#36 -- The README currently claims:
So apparently you've just followed the directions.
Comment #38
jimyhuang CreditAttribution: jimyhuang commentedHi,
I just found memcache-session.inc has wrong hook
drupal 6 style filter_user should be replace to filter_user_update, or user roles can't update correctly.
Comment #39
igor.ro CreditAttribution: igor.ro commentedHere is the patch for http://drupal.org/node/656838#comment-5390822
Comment #40
Firemyst CreditAttribution: Firemyst commentedI've been debugging this some and found the following:
$session->session contains the correct information that one would expect.
$user->session will never exist for when $user->uid == 0 (anon). See http://api.drupal.org/api/drupal/includes%21bootstrap.inc/function/drupa...
What I found in $session->session is a serialized variable of all the messages from drupal_get_messages(), so... wouldn't the accurate thing to be:
This seems to make more sense to me. But I don't know enough about memcache as a whole to know what else this might break... but if the solution so far is: pass empty string back, then I don't see a problem with this.
Of course, I can't find where the returned value is actually used, so does the return matter?
in drupal_session_start(), there's no capturing of the return value. Maybe this is a different bug, though.
Comment #41
Firemyst CreditAttribution: Firemyst commentedI wrote a patch for #40 in case it's useful.
Comment #42
markpavlitski CreditAttribution: markpavlitski commented@Jeremy Would it help to have each of these patches in a separate ticket so they can be RTBC'd?
Comment #43
markpavlitski CreditAttribution: markpavlitski commented#1908358: Incorrect require_once path in memcache-session.inc fixes a WSOD when trying to use memcache-session.inc in the unstable directory.
Comment #44
Firemyst CreditAttribution: Firemyst commentedUpdated the patch I created, since I found an edge case where it's possible for $session to be lost when memcached is restarted.
I've yet to have any warnings using this code. I've also been able to use $_SESSION variables reliably with anon users. Win-win.
Comment #45
markpavlitski CreditAttribution: markpavlitski commented@Firemyst - Can you confirm if this still happens with latest 7.x-dev branch? I can't see an execution path through _memcache_session_user_load() that would result in $user->session not being set.
Outstanding D7 session issues:
#1785744: Memcache Session Handler does not initialize user timezone
#1908348: Session backend fails to update user access time
#577214: $user->session_data_present_at_load is never set in sess_write()
#1908358: Incorrect require_once path in memcache-session.inc
#1984226: Session handler uses D6 hook_user() instead of D7 hook_user_update()
#973228: Port D7 core lazy session writing
Comment #45.0
markpavlitski CreditAttribution: markpavlitski commentedUpdated issue summary
Comment #46
markpavlitski CreditAttribution: markpavlitski commentedComment #47
markpavlitski CreditAttribution: markpavlitski commentedComment #48
pwaterz CreditAttribution: pwaterz commentedIs anyone running this in a production site at this point? If so, are you seeing any issues?
Comment #49
RobKoberg CreditAttribution: RobKoberg commentedInterested as well. Anybody running this on production?
I am using AWS Elastic Beanstalk and having problems with sessions with and without sticky sessions enabled. I am using ElasticCache as my memcache with two nodes. Those nodes are my endpoints in my settings.php. AWS support engineers suggested using ElasticCache to store sessions and then Sticky Sessions could be disabled. I currently have sticky sessions enabled. Have also tried with "Cross-zone load balancing" toggled on and off. I have set this to off. I have three EC2s -- one for each zone.
With this setup I am not seeing any problems from a web browser. But from pings I see timeouts. New Relic is running on each EC2 and also sees png timeouts.
Comment #50
RobKoberg CreditAttribution: RobKoberg commentedI started getting errors in the browser again. So I just enabled sessions and users to use ElasticCache and it seems to be working. I am using 7.x-1.3-rc1. Everything looks like it is working from the browser, but I still have timeouts when I ping from my local machine and new relic still sees timeouts.
My config looks like:
Comment #51
Jeremy CreditAttribution: Jeremy at Tag1 Consulting commentedClosing this out; the memcache module doesn't support sessions.