I am looking into a distributed, replicated session store for multiple Jetty instances. There will be a load balancer (probably nginx and/or haproxy) in front of the Jetty instances.
Specifically, I would like to:
Be able to restart (or crash) one single Jetty instance and have our services available and users still logged in.
Be able to restart (or crash) one single session store instance and have our services available and users still logged in.
The number of sessions will most likely fit on one single machine.
What solutions do you recommend for this? What are your expieriences? Please vote for your favourite option below.
There seems to be a Terracotta session clustering implementation. Haven't tried it myself, but it seems to fit my needs.
Related
I have a web server cluster that contains many running web server instances. each instance cache some configurations in its local memory, the original configurations are stored in Database.
these configurations are used for every request, so the cache may necessary for performance reason.
I want to provide an admin page, in which, the administrator can change the configurations. how do I update all the cache in every server instance?
now I have two solutions for this:
set an expire time for the cache.
when administrator update the configuration, notify each instance via some pub/sub mechanism(e.g. use redis).
for solution 1, the drawback is the changes can not take effect immediately.
for solution 2, I'm wondering, if the pub/sub will have impact on the performance of the web server.
which one is better? or is there any common solution for this problem？
Another drawback of option 1 is that you'll periodically hit your database unnecessarily.
If you're already using Redis then option 2 is a good solution. I've used it successfully and can't imagine how there could be a performance impact just because you're using pubsub.
Another option is to create a cache invalidation URL on each website, e.g. /admin/cache-reset/, and have your administration tool call the cache-reset URL on each individual server. The drawback of this solution is that you need to maintain a list of servers. If you're not already using Redis it could just be the simple/practical/low-tech solution that you're looking for.
There are 2 homogeneous clusters and these fall under a common domain.
cluster1 has different app servers than cluster2.
How to manage session between these clusters?
How to authenticate cluster1-app-server created sessionId(session) in cluster2-app-server
or Is there a common place I can create jsessionId(session) and make it not a container specific implementation?
hazlecast or tomcat gives session replication/management inside a homogeneous cluster.
How to take this between clusterS ?
Any data point is much appreciated.
Is shiro suited for this?
Shiro works well within one machine, it keeps a session in memory. Having it authenticate the same session to another place would require setting tokens on the session, which the other machine recognizes and you would have to write custom code for that.
I think you are better of by using some kind of single signon server like CAS.
http://jasig.github.io/cas/4.0.0/index.html
I am trying to develope an application with tomcat running in several computers of same LAN trying representing several nodes and each of them runs an application with a single shared session(Ex. shared document editor such as google docs.). in my understanding so far I need a single shared session and several users need to update the doc symultaneously and each others updates are reflected on each others we interfaces almost imidietly. Can I acheve this with with tomcat's clustering feature. http://tomcat.apache.org/tomcat-7.0-doc/cluster-howto.html#Configuration_Example or is this just a faluir recovery system.
Tomcat's clustering feature is meant for failover - if one node fails, user can carry on working while being transparently sent to another node without a need to log in again.
What you are trying to achieve is a totally different scenario and I think using session for this is just wrong. If you go back to Google Doc example, how would you achieve granting (revoking?) document access to another user? What do you do when session times out - create the document again? Also, how would you define which users would be able to access selected documents?
You would need to persist this data somewhere (DB?) anyway so implement or reuse some existing ACL system where you could share information about users and document permissions.
I have a standard web application deployed to an application server.
The application uses Struts 1, iBatis, JSP, Servlets, pretty basic stuff.
Now the application will be deployed to a Weblogic cluster. Is there anything in particular I need to rework so that the application may be deployed to a cluster, for instance, how about transactions?
Or is deploying to a cluster invisible to the developer?
Looking for general things to look into, things that for sure need to be done when a web application is deployed to a cluster.
I would recommend minimizing session data. Session data either forces a user to be "sticky" (once they use one particular server they have to keep going there) or the clustering software has to replicate all sessions to all servers.
Think hard about thread safety. You don't want a situation where one user can ever see another's private data.
Also look at you database isolation. You have to strike the right balance between serializable transactions and performance.
I would like to know any experience with the Tomcat Session Cluster solution. Is it production level? Does it scale? Can I use it in a server farm? Do you recommend any other solution for a session cluster? (Ex: database, terracota, jgroups, etc.)
Another alternative would be the memcached-session-manager, a session failover solution for tomcat: http://code.google.com/p/memcached-session-manager/
I created this project to get the best of performance and reliability and to be able to scale out by just adding more tomcat and memcached nodes.
Cheers,
Martin
From all the documentation I've read, it will work fine for a few number of instances but then become an issue.
We use Tomcat as our backend servers but design our applications to use as little session information as possible (basically just logins). Then we front the Tomcats with a load balancer like Apache or Nginx (the later which I'm favoring recently) and use sticky sessions. If a server goes offline (which is unlikely) then the user simply needs to login again, which depending on how you set it up could be transparent to them.
When I was looking to do more session based clustering, Terracotta looked very impressive. But stateless design makes scaling much easier.