kandi X-RAY | memcached-session-manager Summary
kandi X-RAY | memcached-session-manager Summary
memcached-session-manager is a tomcat session manager that keeps sessions in memcached or Redis, for highly available, scalable and fault tolerant web applications. It supports both sticky and non-sticky configurations, and is currently working with tomcat 6.x, 7.x, 8.x and 9.x. For sticky sessions session failover (tomcat crash) is supported, for non-sticky sessions this is the default (a session is served by default by different tomcats for different requests). Also memcached failover (memcached crash) is supported via migration of sessions. There shall also be no single point of failure, so when a memcached fails the session will not be lost (but either be available in tomcat or in another memcached).
Top functions reviewed by kandi - BETA
- Performs warmup operation .
- Creates a new MemcachedNodesManager for the given MemcachedNodes .
- Performs the backup operation .
- Loads a backup session from memcached .
- Backup a session to memcached .
- Deserialize session fields .
- Creates the Kryo factory .
- Invoked after a session has been initiated .
- Handles the request .
- Handle a GET request .
memcached-session-manager Key Features
memcached-session-manager Examples and Code Snippets
Trending Discussions on memcached-session-manager
I'm currently using memcached-tomcat-session-manager with Tomcat7 for session storage.
This is setup in the prescribed manner with the various memcached / transcoder / serializer JARs in
$CATALINA_HOME/conf/context.xml with a
... entry and works just fine.
A situation has arisen where I'd like to share some
static properties of classes between my webapp and (my modified version of) memcached-session-manager. I believe with the current setup they are in separate classloaders, so sharing static resources between classes is not possible.
That led me to bundle all the dependencies with the
/WEB_INF/lib and move the the
/META-INF/context.xml. This is not working, with Tomcat reporting:
ANSWERAnswered 2019-Jan-02 at 00:01
memcached-session-manager (msm) jars must reside in
$CATALINA_HOME/lib because they're using tomcat internal classes (which is not possible from within the webapp). More concretely, these jar are
The only msm related jars that must be put in
/WEB_INF/lib are serialization related jars such as
msm-kryo-serializer (usually defined as dependencies in your maven/gradle/xyz build), because they must be able to access application specific classes.
See also the related msm documentation.
Regarding your goal to share information between msm and your application: Because msm jars must reside in
$CATALINA_HOME/lib, conceptually it's not possible to statically "link" application code with msm code (except msm serializer related code). This is only possible with an additional indirection: the definition of some interface inside msm, where the application provides an implementation and which msm then loads via reflection. This is how serializers are hooked into msm, see the TranscoderFactory interface (loaded from
$CATALINA_HOME/lib) and the KryoTranscoderFactory implementation (loaded from
I am setting up a Tomcat application in EC2. For reliability, I am running two or more instances. If one server goes down, my users should be redirected to the other instance. This suggests that session state should be kept in an external source, or mirrored between the servers.
AWS offers a hosted service, Elasticache, which seems like it would work well. I even found a nice library, memcached-session-manager. However, I soon ran into some issues.
- Unless someone can convince me otherwise, I need the session states to be encrypted in transit. Otherwise someone could intercept the network traffic and pretend to be someone else on my site. I don't see any built-in Amazon method to keep traffic off the internet. (Is peering available here?)
- The library mentioned earlier does have Redis support with SSL, but it does not support a Redis cluster. Someone put in a pull request for this but it has not been incorporated and this library is a complex build. I may talk myself into living without the cluster, but that puts us back at a single point of failure.
ANSWERAnswered 2017-Nov-30 at 23:36
Tomcat is running on EC2 in your VPC, and ElastiCache is in your VPC. Your AWS VPC is an isolated network. Nobody can intercept the traffic between the EC2 and Elasticache servers unless your VPC network becomes compromised in some way.
If you want to use Redis instead, with SSL connections, then I believe at this time you would need a Tomcat Session Manager implementation that uses Jedis. This one uses Jedis, but you would need to upgrade the version of Jedis it uses in order to use SSL connections.
No vulnerabilities reported
Reuse Trending Solutions
Subscribe to our newsletter for trending solutions and developer bootcamps
Share this Page