redundancy ?

[Klaus Grønbæk]

I'm on EC2 and having problems with Tomcats normal session replication and wanted to see if msm could solve my problems. 

On the nice ASCII drawing (https://code.google.com/p/memcached-session-manager/wiki/SetupAndConfiguration) you have t1 using m2 and t2 using m1. To me this is not a redundant setup, it's true that if t1 crashes its sessions survives on m2, but all users currently using t2 have lost their sessions on m1. How do you setup a scenario with transparent failover?

Memcached nodes don't talk together by default, this is different from technologies like Hazelcast where you can specify the number of backup nodes, ensuring that data is not lost when a single node crashes.

Regards,

Klaus Grønbæk

P.s. I very much like the simplicity of configuring msm

[Martin Grotzke]

On 04/26/2013 10:11 AM, Klaus Grønbæk wrote:
> I'm on EC2 and having problems with Tomcats normal session replication
> and wanted to see if msm could solve my problems.
>
> On the nice ASCII drawing
> (https://code.google.com/p/memcached-session-manager/wiki/SetupAndConfiguration) you
> have t1 using m2 and t2 using m1. To me this is not a redundant setup,
> it's true that if t1 crashes its sessions survives on m2, but all users
> currently using t2 have lost their sessions on m1.

The drawing refers to sticky sessions. With sticky sessions all sessions
from t2 are still available in t2 itself (the session map).

If you're using non-sticky sessions a backup is stored in another
memcached node, so this would also be handled.

Does this answer your question?

> How do you setup a
> scenario with transparent failover?
> Memcached nodes don't talk together by default, this is different
> from technologies like Hazelcast where you can specify the number of
> backup nodes, ensuring that data is not lost when a single node crashes.

You can also use e.g. membase as backend.

Cheers,
Martin

>
>
> Regards,
> Klaus Grønbæk
> P.s. I very much like the simplicity of configuring msm
>

> --
>
> ---
> You received this message because you are subscribed to the Google
> Groups "memcached-session-manager" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to memcached-session-...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

--
inoio gmbh - http://inoio.de
Schulterblatt 36, 20357 Hamburg
Amtsgericht Hamburg, HRB 123031
Geschäftsführer: Dennis Brakhane, Martin Grotzke, Ole Langbehn

[Klaus Grønbæk]

That clarifies it, the session still lives in memory, and a copy of it is replicated to another machine's memcache.

Got it working with Elastic Load Balancer and Tomcat (no mod_jk).

Thanks,

Klaus 

> an email to memcached-session-manager+unsub...@googlegroups.com.

[Martin Grotzke]

Great it's working for you!

Cheers,
Martin

On 04/26/2013 11:17 AM, Klaus Grønbæk wrote:
> That clarifies it, the session still lives in memory, and a copy of it
> is replicated to another machine's memcache.
>
> Got it working with Elastic Load Balancer and Tomcat (no mod_jk).
>
> Thanks,
> Klaus
>
>
>
> On Friday, April 26, 2013 11:03:14 AM UTC+2, Martin Grotzke wrote:
>
> On 04/26/2013 10:11 AM, Klaus Grønbæk wrote:
> > I'm on EC2 and having problems with Tomcats normal session
> replication
> > and wanted to see if msm could solve my problems.
> >
> > On the nice ASCII drawing
> >
> (https://code.google.com/p/memcached-session-manager/wiki/SetupAndConfiguration

> <https://code.google.com/p/memcached-session-manager/wiki/SetupAndConfiguration>)

> > an email to memcached-session-...@googlegroups.com
> <javascript:>.

> > For more options, visit https://groups.google.com/groups/opt_out

> <https://groups.google.com/groups/opt_out>.