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.
Related
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 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.
We have four public websites running on the same database with different schema(Oracle). All of them are 'AAA' application and have "20,0000PV~500,000PV"daily. 90% data in websites are read-only and updated daily(By Batch). Less than 10% data, such as announcement, are updated manually. We are looking for the best practices to solve following concerns.
Improve website availability. Though we have a BCP database, it might need 1~2 hours to recover 4 websites in case database server is down.
Since most data are read-only, we are considering using in-memory db (hsqldb) or cache component(ehcache) to improve performance. As default, we are using ibatis and hibernate. Ehcache might not only be used on Level-2 cache, but also page cache.
We trends to build web services framework(restful) instead of java solution since mobile application might reuse them. Not very sure if it is a good idea to run website on web service on the same web application server. We have active-active HTTP and web servers.
On-line shopping is in the future plan.
Add database processes, make it at least 4 for serving each website.
Consider memcache
The same application server can run multiple applications. Not a problem it there is a good amount of RAM. However, if there is an overwhelm of users, you can always move particular applications to a different server. But, a better idea is to wait and see which service is worth that privilege.
Another web-application, too much of security and state management. Better put it in a new server.
I am working on this quiet a while, but still no conclustion.
I want to do horizontal scaling of Tomcat instances in Microsoft Azure (1,2,3,... Tomcat instances for one service). I read lots of articles about session replication, clustering,... with Tomcat. Since Azure does not support Multicasts, there is no easy way to cluster Tomcat. Also sticky sessions is no options, because Azure does round robin load balancing. Setting up two services - one with Terracotta or Apache mod_jk - and the other with Tomcat instances seems overkill for me (if even doable)...
Is this even possible?
Thanks in advance for reading and answering my question. Every comment/idea is highly appreciated.
There is the new appFabric caching service you could use, or there are examples of using Memcache on Azure, would that help?
http://code.msdn.microsoft.com/winazurememcached
Why do you feel that running 2 services is overkill, exactly? If you have no issue with scaling out to n Tomcat instances, adding another service for load distribution is a perfectly acceptable solution in my book. By running that service on a minimum of 2 instances, that service itself meets the Azure SLA requirements: your uptime will be as good as it is going to get on Azure, and you avoid a SPoF (single point of failure).
You could go with a product like terracotta, but it is also pretty straightforward to write a simple socket server to route HTTP sessions back to a particular instance running in Windows Azure. You would have to be aware of node recyles, but that is quite doable.
Be aware that memcached requires an additional Azure service as well (web roles), the appFabric caching service does not (but also has cost associated with it). I do not know Tomcat, but for IIS you can easily move session state from in memory to persisted (either SQL Azure or Azure Storage). Something to be aware of: for high volume sites, the transaction cost to Azure Storage can actually become a cost driver for your deployment if you store session info there. SQL Azure could well be the more cost-effective solution, but on the other hand might not be supported out-of-the-box for your solution.
I do not think that you can run Tomcat on Azure. Even if you could (using the virtual machine role) it is probably cheaper to run it on a Linux VM on Amazon EC2.
Edit
I see that this is possible using the Tomcat Solution Accelerator. But look at the disclaimer:
This solution accelerator is provided
for informational purposes only and
Microsoft or Infosys makes no
warranties, either express or implied
This is an unsupported solution. I know that it is often difficult to question management decisions. But using unsupported software for production systems, when a cheaper supported alternative is available, is generally not a good idea.
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.