We have a Tomcat cluster with two instances (version 5.5.25) running on a single machine. We use this to make sure our web page is available and that all sessions survive during redeployment.
We were wondering if sessions could be lost during this procedure. Here is what we do:
a) Application is running on tomcatA and tomcatB and all sessions are replicated
b) Application on tomcatA is undeployed, all requests are redirected to tomcatB
c) Application on tomcatA is deployed
* Now the cluster needs to make sure that all sessions are replicated properly on tomcatA
d) Application on tomcatB is undeployed, all requests are redirected to tomcatA
e) Application on tomcatB is deployed
We use an ant script and the tomcat manager tasks to control the deployment procedure. Note that we are not actually bringing down any tomcat instances, but rather we're just redeploying a particular application while the rest are still running.
Could sessions be lost in this procedure when the undeployment of the webapp on tomcatB happens right after the deployment on tomcatA?
Does the tomcat manager deploy task in step (c) only return once all sessions are successfully replicated?
If not is there a way to ensure all sessions are replicated before undeploying the webapp on tomcatB?
Thanks,
Mitko
Related
For the first time I am working in an environment where we deploy components in multiple docker containers. The log files in each component are indexed by splunk. In our example we have a legacy JSP app running in container A that invokes restful API deployed in container B (spring-boot). The issue I am running into is connecting the user request in container A to the restful API in container B.
Basically I want a cohesive sequential view of all the code that was executed to process a user's request. I think I will have to log using some type of unique identifier that is attached to a user but shared across all containers. Is there some established pattern to do this?
I am trying to deploy a Go application inside the Kubernetes cluster. My application uses the goracle.v2 library to connect to the Oracle database.
The problem only happens when my application is running inside the Kubernetes cluster. I have a process that executes a stored procedure and returns a cursor, and it often takes more than 10 minutes to execute.
When this happens the active session that was there in the database ends and the pod that was running with the application is stopped and nothing else happens. And this scenario only happens when it runs inside the cluster. If I run the app locally it doesn't happen even if the process takes more than 10 minutes.
Anyone have any idea what might be happening?
I have two servers in a HA mode. I'd like to know if is it possible to deploy an application on the slave server? If yes, how to configure it in jgroups? I need to run a specific program that access the master database, but I would not like to run on master serve to avoid overhead on it.
JGroups itself does not know much about WildFly and the deployments, it only creates a communication channel between nodes. I don't know where you get the notion of master/slave, but JGroups always has single* node marked as coordinator. You can check the membership through Channel.getView().
However, you still need to deploy the app on both nodes and just make it inactive if this is not its target node.
*) If there's no split-brain partition, or similar rare/temporal issues
Hadoop YARN includes a configuration to modify how many times an application can be started: yarn.resourcemanager.am.max-attempts.
I am interested in hitting this limit to observe how the system may fail, and I want to be able to do it without modifying code. To mimic production scenarios, I would like to turn off other Hadoop services to cause a second attempt of the application.
What services can I turn off during the application run to trigger another application attempt?
For simplicity, just close storage services(hosting your source data or target data). For example, hdfs service, hive service, etc.
I'm deploying my Grails (2.3.6) app with the Grails Standalone App Runner plugin, like so:
grails -Dgrails.env=prod build-standalone myapp.jar --tomcat
Then, my CI build places myapp.jar onto my app server, say, myapp01.
I now want to cluster app sessions when myapp is running on multiple nodes. So if myapp gets deployed to myapp01, myapp02 and myapp03, and one of those instances starts a new session with a user, I want all 3 to be aware of the same session. This is obviously so I can put all the nodes behind a load balanced URL (http://myapp.example.com, etc.) and it doesn't matter what node you get routed to: all nodes share the same sessions.
I googled "grails session clustering" and see a bunch of articles that seem to require terracotta, but I also heard that Grails has built-in session clustering facilities. But any searches I do come back empty-handed.
So I ask: How can I achieve this kind of session clustering with an embedded Tomcat?
Besides the seesion-cookie plugin that #injecteer proposed, there are several other plugins allowing to keep sessions in a shared storage (DB, mongodb, redis, memcached) that can be accessed by any of your tomcat instances. Take a look at these:
http://grails.org/plugin/database-session
http://grails.org/plugin/mongodb-session
http://grails.org/plugin/redis-database-session
http://grails.org/plugin/standalone-tomcat-redis
http://grails.org/plugin/standalone-tomcat-memcached
I never heard of something like this out-of-box. I would give 2 options a try:
Use a session-cookie plugin, with which you decouple your clients from storing the sessions in tomcat
Use or implement persistent sessions, which are stored in some sort of DB and are not bound to any tomcat instance.
You could achieve this by using the tomcat build-in functionality. Tomcat instance node could replicate session from others, then all the session get shared between nodes.
You can do this in at least three ways:
Session Replication by using Muilcast between instance nodes.
Session Replication just between primary and secondary node backup.
Session Replication between Static Memberships, this one is useful when the multicast cannot be enabled or supported such as in AWS EC2 Env.
Reference:
http://tomcat.apache.org/tomcat-7.0-doc/cluster-howto.html
http://khaidoan.wikidot.com/tomcat-cluster-session-replication