[imp] memcached sessions

[Liam Hoekenga]

I'd be very interested in seeing this code!

You could also try using the mcache extension 
(http://www.klir.com/~johnm/php-mcache/) instead of the memcached 
extension.  mcache wraps libmemcache, and unlike the memcached extesion, 
it supports pooled servers.

It had had some issues with trying to connect to non-existant servers.. 
previously it would segfault.  Our interest in using pooled servers is for 
fault tolerence, and it was kinda pointless if it couldn't handled downed 
servers gracefully.

The latest version 1.2.0b9 seems to handle the situation better.  It 
returns..

[Tue Oct 25 17:18:14 2005] [error] PHP Warning:  mcm_server_add3():2076: 
unable to lookup/resolve host: Name or service not known

Anyhoo.. I'd love to see the memcached and mcache extensions merge into 
one accepted PECL extension.. but in the mean time, the horde memcached 
session handler is very easily adapted to the mcache extension.  I'll 
provide my changes once I figure out how to make the horde configuration 
tool work.

Liam

On Thu, 13 Oct 2005, Kevin M. Myer wrote:

> Quoting Didi Rieder <adrieder at sbox.tugraz.at>:
>
>> Could you share that code?
>> How about doing the writes to all the server (which are available)
>> and doing the
>> reads from one randomly picked (if the server is not available or has not the
>> desired info, try the next).
>
> I was going to put it in the bug tracker as an enhancement.  I'll try to get
> that done by the end of the day today.
>
> There are several end results you could be trying to achieve with any session
> handler:
>
> 1)  Basic functionality (1 server stores all session data)
> 2)  A means for providing shared access to session data (2 or more
> servers store
> session data, data divied up by some algorithm, with each sessionid having
> affinity for one memcached server, based on the algorithm, helps address
> scalability)
> 3)  A means for providing shared access to session data and replicating
> session
> data (2 or more servers store session data, with Horde handling replication of
> data across all servers, helps address scalability and high availability)
>
> What I was working on would only implement 1 and 2, although 3 might be
> possible.  The problem I see with replicating anything is you don't
> have a good
> way of guaranteeing the data gets replicated.  For instance, if you are using
> two servers and have one session...  You write the session info to both the
> first time.  A network problem temporarily drops the connection to the second
> server, so the first server is used for reads and writes exclusively.
> You need
> code to detect when server 2 comes back.  And when it does come back,
> its going
> to have stale session data, if any writes were done to server 1.  So if you do
> a read to server 2, you're going to get different results than if you read
> server 1.  So I think doing replication might be tricky, because there's no
> good way to determine the state of the information across multiple
> servers. Now if you had a way to pool memcached, so that it handled
> replications itself
> (say by specifiying peers to the memcached process at startup, and if a change
> was received, that information was passed to all peers by the memcached
> process), that might be interesting, but it would also add complexity and the
> overhead of trying to maintain consistency might kill the speed.  Always
> tradeoffs somewhere..
>
> A different set of issues arises with simple shared access to session data,
> namely that if you lose a server, the portion of your users who have session
> data stored there are suddenly going to be orphaned.  I believe Liam at UMich
> had proposed a sessionhandler with a fallback mechanism, should the preferred
> mechanism go away for whatever reason.  Maybe that could get
> implemented in the
> general SessionHandler class - try a driver-based handler, if a connectivity
> failure is detected there, fall back to something that should always work.
>
> And there's probably a bunch of cases or scenarios I've overlooked.
>
> Kevin
> -- 
> Kevin M. Myer
> Senior Systems Administrator
> Lancaster-Lebanon Intermediate Unit 13  http://www.iu13.org
>
>
> -- 
> IMP mailing list - Join the hunt: http://horde.org/bounties/#imp
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: imp-unsubscribe at lists.horde.org
>
> !DSPAM:434e54f3282202050710175!
>
>
>
>