memcached as a session store - store sessions in 2 nodes for failover

[martin.grotzke]

Hi,

I'm just thinking about using memcached as a session store. For
handling node failures and node adds/removals the normal way is to
store sessions in the database and use memcached as the caching
layer.

Quite reasonable, however I want to think about an alternative: Would
it be possible to store the session in two memcached nodes, so that
the 2nd node is chosen if the primary node is not there (or the
session is not found in this node)? One could put the session in the
primary node and the "next" node. Together with consistent hashing
both node failures and adding new nodes should be handled well.

My questions:
- Is it possible to determine the "next" node based on the primary
node? Is this provided by KetamaNodeLocator.getSequence?
- Is it possible to tell the MemcachedClient to which node it shall
write the data? (how can I tell memcachedclient to send the data to 2
nodes?)
- Are there issues with this approach (apart from that sessions should
better go to a persistent store)?

Thanx && cheers,
Martin

[philc]

Good to see this post. I have having exactly the same thoughts,
however we would look to be able to explicitly define groups of
memcached servers (primary, backup, 3rd level etc) to ensure that the
primary and backup memcached server instances are not on the same
physical nodes.

Obviously having the client serialize PUT data once and send to both
servers is more efficent than sending the data twice.

Phil


On Mar 8, 11:44 pm, "martin.grotzke" <martin.grot...@googlemail.com>
wrote:

[steve.yen]

This might not apply to all apps, but another interesting idea is to
use both memcached and the db,
with the db as a eventually updated write-back session store...

http://dormando.livejournal.com/495593.html

[Martin Grotzke]

Ah, the idea of groups sound also nice - I like that!

However, in the meantime my mind changed and I'd prefer using the database as this is really failsafe (as long as the database is available :)).

Cheers,
Martin

2009/3/12 philc <phil.c...@gmail.com>

--
Martin Grotzke
Bernstorffstr. 17, 22767 Hamburg
Tel.      +49 (0) 40.98239888
Mobil     +49 (0) 170.9365656
E-Mail    martin....@googlemail.com
Online    http://www.javakaffee.de

[martin.grotzke]

What I'm also just thinking about: using sticky sessions (as wicket
seems to require them) and memcached as a session failover solution.

I have s.th. like that in mind: Use standard HttpSessions in memory
and write sessions to memcached nodes. This should be done by a
servlet Filter, that is configured with a certain memcached node
address to which it sends the session at the end of doFilter (provided
there's a session). Additionally the filter adds a cookie to the
response that stores the memcached node where the session is located.

When a server goes down and the load balancer routes the request to
another server the filter will check if a session is requested but not
available locally (in memory) and fetch the session from the memcached
node. Then the session must be registered in the local session store
of the servlet container - and that's where this filter approach is
limited.

So it seems one needs to do this in a custom session manager that is
registered with the servlet container (for tomcat see
http://tomcat.apache.org/tomcat-6.0-doc/config/manager.html). The
drawback obviously is that one is bound to a certain container then.

I have to think a bit more about this, but right now this seems to be
an option for session failover and scalability.

Cheers,
Martin



On Mar 14, 5:51 pm, Martin Grotzke <martin.grot...@googlemail.com>
wrote:

> Ah, the idea of groups sound also nice - I like that!
>
> However, in the meantime my mind changed and I'd prefer using the database
> as this is really failsafe (as long as the database is available :)).
>
> Cheers,
> Martin
>

> 2009/3/12 philc <phil.clari...@gmail.com>

> E-Mail    martin.grot...@googlemail.com
> Online    http://www.javakaffee.de

[martin.grotzke]

I implemented this and just posted a description here:
http://www.javakaffee.de/blog/2009/03/19/started-memcached-session-manager-project-session-failover-with-memcached/
:)

Cheers,
Martin


On Mar 14, 6:10 pm, "martin.grotzke" <martin.grot...@googlemail.com>
wrote:

> What I'm also just thinking about: using sticky sessions (as wicket
> seems to require them) and memcached as a session failover solution.
>
> I have s.th. like that in mind: Use standard HttpSessions in memory
> and write sessions to memcached nodes. This should be done by a
> servlet Filter, that is configured with a certain memcached node
> address to which it sends the session at the end of doFilter (provided
> there's a session). Additionally the filter adds a cookie to the
> response that stores the memcached node where the session is located.
>
> When a server goes down and the load balancer routes the request to
> another server the filter will check if a session is requested but not
> available locally (in memory) and fetch the session from the memcached
> node. Then the session must be registered in the local session store
> of the servlet container - and that's where this filter approach is
> limited.
>
> So it seems one needs to do this in a custom session manager that is

> registered with the servlet container  (for tomcat seehttp://tomcat.apache.org/tomcat-6.0-doc/config/manager.html).  The