Re: Memcache session handler

Hi, That's the thing that is worrying me at the moment, not knowing where sessions are being stored when the pool is down. I've tried to look over the CVS code, but I don't have enough knowledge to understand it all. I may have to write my own PHP based handler after all :) Thanks. "Glenn Richmond" <glenn.richmond@ilisys.com.au> wrote in message news:455E7DF9.5080009@ilisys.com.au... > Hi Chris, > > The sessions are just stored directly in the memcache server RAM at this > point. If all servers are down, you'll have no sessions. The intention is > to add a mysql back end at some point, but no eta on this yet. > > I'm not sure how or why your sessions are still working when all servers > are down :) > > Best Regards, > > Glenn. > > Chris wrote: >> Hi, >> >> I'm glad I found this feature. I had just started writing my own session >> handler functions for memcache but then I found this. >> >> However, I need to know what happens when the whole server pool is down? >> I purposely stopped all my memcache servers but sessions are still >> working just fine with storing and updating data. >> >> Where are the sessions being stored? Theres nothing in /tmp >> >> Thanks. >> >> >> "Mikael Johansson" <mikael@synd.info> wrote in message >> news:454147F0.4070406@synd.info... >> >>> The CVS version of pecl/memcache now has session support, you may check >>> out and build a copy as >>> >>> cvs -d :pserver:cvsread@cvs.php.net:/repository checkout pecl/memcache >>> cd pecl/memcache >>> phpize >>> ./configure >>> make >>> make install >>> >>> The session save handler is activated from INI as >>> >>> session.save_handler = memcache >>> session.save_path = >>> "tcp://host1:11211?persistent=1&weight=2,tcp://host2:11211" >>> >>> The parameters accepted on the url are "persistent", "weight", >>> "timeout" >>> and "retry_interval" (same as to Memcache::addServer().) You may add any >>> number of servers separated by commas. The new unix domain socket >>> feature may also be used as "unix:///path/to/memcache.sock:0" >>> >>> Feedback and help with testing would be most appreciated. >>> >>> //Mikael >>> >>> Glenn Richmond wrote: >>> >>>> Hi Mickael & Antony, >>>> >>>> I've attached the key session handling code for the memcache handler. >>>> It >>>> uses libmemcache as the back end, so naturally the function calls will >>>> be slightly different when adding to the memcache extension. At the >>>> moment, I configure the system in the php.ini with the following >>>> settings: >>>> >>>> session.save_handler="memcache" >>>> session.memcache_server_1="xxx:xxx:xxx:xxx:11211" >>>> session.memcache_server_2="xxx:xxx:xxx:xxx:11211" >>>> >>>> At the moment, the first server is compulsory, but the second is >>>> optional. I integrated it directly with the standard files and user >>>> session handlers initially just to test the theory, but we should be >>>> able to separate now i think. Let me know what your thoughts are - >>>> whether you want me to have a go at integrating it or if you want to >>>> take the existing code and just port it. >>>> >>>> Best Regards, >>>> >>>> Glenn Richmond. >>>> >>>> Mikael Johansson wrote: >>>> >>>>> I agree with Antony, there shouldn't be a problem integrating session >>>>> handling into pecl/memcache. Some questions though >>>>> >>>>> * The extension needs to know the address of the servers in order to >>>>> connect, so how do you start the session? >>>>> >>>>> 1) From php.ini using something like >>>>> >>>>> memcache.session_storage = >>>>> >>>>> "tcp://node01.example.com:11211?weight=2,tcp://node02.example.com:11211" >>>>> session.save_handler = memcache >>>>> >>>>> 2) From your script as >>>>> >>>>> $memcache = new Memcache(); >>>>> $memcache->addServer(...); >>>>> $memcache->registerSessionHandler(); >>>>> session_start(); >>>>> >>>>> * Memcache (as with any other cache) is inherently unreliable and >>>>> might >>>>> garbage collect keys in a LRU fashion should it need the memory for >>>>> other keys. One might be able to mitigate this issue by ensuring that >>>>> memcache has plenty memory, but until there's a (per key) DO_NOT_GC >>>>> flag >>>>> implemented in memcached there's always the risk of sessions being >>>>> dropped. >>>>> >>>>> Better to have a 2-tier session storage where writes are passed >>>>> through >>>>> to a database (shared by all the web front ends) and reads are handled >>>>> by the cache. For example: >>>>> >>>>> >>>>> http://svn.synd.info/synd/trunk/core/lib/SessionHandler.class.inc >>>>> >>>>> But if you need the performance of storing the session only in >>>>> memcached >>>>> and are aware of the potential problems, you should be able to do so. >>>>> >>>>> If you wouldn't mind posting a link to your code and a patch against >>>>> the >>>>> current CVS head we'll try and integrate it as soon as possible. >>>>> >>>>> //Mikael >>>>> >>>>> Glenn Richmond wrote: >>>>> >>> [snip] >> >>