Apache Tomcat 7: Overview, Clustering, End of Life
Apache Tomcat is one of the most popular open source web application servers. Here, we give an overview of Apache Tomcat 7, including clustering options, end of life considerations, and how to get support.
Tomcat 7 Overview
Tomcat 7 is a version of Apache Tomcat released in 2011. More recent versions of Tomcat include Tomcat 8,Tomcat 9, and Tomcat 10.
Now Available: The Enterprise Guide to Apache Tomcat
From performance and security to clustering and resilience, our Enterprise Guide to Apache Tomcat is a great resource for teams using or considering Tomcat for enterprise applications.
Apache Tomcat 7 Clustering Tutorial
Here's how to create your own Tomcat 7 cluster. Whether you have created many Tomcat clusters in the past or this is your first attempt, we hope that you will be able to learn something, whether it be basic or advanced, from this blog. To limit the liability of your attempt at creating a cluster, you can set up a machine, virtual or physical, just for this task.
Note: You can run multiple tomcat instances on a single virtual/physical machine by tweaking a just few settings, mainly port numbers so the instances don't interfere with each other. The configuration of these tomcat instances is well outside the scope of this document, although it is not difficult to accomplish. Settings for the connectors in your server configuration files can be found at the Apache Tomcat 7 website.
1. Create Your Tomcat 7 Cluster
Tomcat 7 clustering is very simple to setup. However, if you wish to leverage clustering in your enterprise environment, the default configuration is not going to be the best route for you. To turn on clustering in your Tomcat server all you have to do is add one line of code to your server.xml.
<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"/>Adding this line to your configuration enables clustering with all of the default settings. This would be great if you were not in an enterprise setting.
You have created a clustered instance, but you only have one instance, so it is not a very big cluster. Before we create the next instance we should install the application we want to test on this cluster.
2. Make your Web Application Distributable
With your cluster running, placing a normal application on one server will not trigger propagation to other servers. The idea behind propagation is: an application is placed on one "node" in the cluster, it is migrated (copied) automatically to other nodes in the cluster. To achieve this we add the following code to the web.xml:
<distributable/>
This tells Tomcat that this application is designed to run on multiple nodes in this cluster.
Note on Default Settings
All to all session replication means any session data created on a server will be duplicated to all other servers in the cluster. If you application creates session data for a user, and you have a heterogeneous cluster, the session data will still be replicated across the other nodes. If you recall from last month's blog, a heterogeneous configuration is one that does not have all of the same applications on every node. Therefore, if application A stores session data for a user, and application A is running on server A, but not server B, session data will replicate to server B, even though there is no use for it there.
Default multicast setup means the cluster is discovered and maintained via multicast heartbeats. The server will be set up with a default multicast ip address of 228.0.0.4 and a multicast port of 45564. This means, any other nodes that are using the same multicast address and port will see this cluster / node.
3. Determine Your Best Fit
There are certain questions you need to ask when setting up the cluster for your organization. How many users do I have? How many simultaneous requests do I need to be able to serve? How many applications am I running? What resources are available on our servers for these applications? The list goes on and on. Only you can figure out what kind of cluster configuration you need.
If you need a large cluster, either because you have memory and processor intensive applications that need multiple servers, or because you serve millions of requests a day, you need to set it up differently than you would a small cluster.
If you need a small cluster, of about one to six nodes, it will be configured differently. The main difference will be the method of session replication.
Whether you are creating a large cluster or a small cluster, the basics are the same.
4. Configure Your Tomcat 7 Instances
The first step is configuring your Tomcat 7 instances. You need all of the instances, whether there is 2 or 500, to run properly without being in a cluster. Once your nodes are running, you know they will function in a cluster, and if they don't then something is wrong with your clustering configuration.
After creating the "Cluster" object and making your web applications distributable, both shown previously in this blog, we need to move on to configuring other settings.
5. Define the Manager Object
The Manager object controls session replication.
<Manager
className="org.apache.catalina.ha.session.DeltaManager".../>
The "DeltaManager" replicates all changed session data to all nodes of the cluster. The "BackupManager" backs up session data to a specific "backup" node. For large clusters the BackupManager is the option to go with, for smaller clusters it is common to just use the default Delta Manager.
In Tomcat 7, you can define a manager in the cluster configuration, as you could in earlier versions. But you can also define a manager in a web application's context.
Defining the Manager in your clustering configuration provides a default setting for applications that do not provide their own Manager configuration. For instance, the following code will set all applications in your cluster to use the BackupManager for session replication.
<Manager
className="org.apache.catalina.ha.session.BackupManager".../>
6. Set Channel Send Options
After setting the Manager, you might need to apply a non-default channel send options value. Channel send options is a setting specified on the
Cluster object. For ex.:
<Cluster
className="org.apache.catalina.ha.tcp.SimpleTcpCluster"
channelSendOptions="6">
Channel send options controls how messages are sent between cluster nodes. Are these message sent synchronously, or , in layman's terms, does the thread that sends the message have to wait until the message has sent before continuing to work, in turn, potentially making the users request wait on this message to be sent? Sending the messages asynchronously is when the thread generates and sends the message, but does not stop and wait for this to happen. It does this by spawning a worker thread.
As you can see, this is just one aspect of the channel send options, and it is a lot of information. To go over channel send options in detail will require a whole default channel send mode is asynchronous.
When Is Tomcat 7 End of Life?
Tomcat 7 end of life is March 31, 2021 from Apache — but Apache isn't your only option for Tomcat 7 support.
Get Help With Tomcat 7 Clustering
This discussion barely scratches the surface of clustering. What we have provided is a starting point for your cluster. With the information provided here you can start a cluster containing two or one thousand nodes. Please remember, OpenLogic can optimize your cluster for you.
No matter what happens, from your configuration being a little out of whack to your entire enterprise cluster crashing, OpenLogic will be there to support you. Based on your ability, we can consult with your company if need be, to create and configure your cluster, in addition to providing for all of your clustering support needs.
If your organization needs assistance with it's cluster, or you are having problems with nodes disappearing, nodes not joining cluster, session information being lost, random node crashes, or anything cluster or Tomcat related, just contact OpenLogic support. We will provide you with an easy-to-implement solution.
Get Dependable Tomcat Support
Get Tomcat support you can trust. OpenLogic provides 24/7 support for Tomcat 7, as well as more recent versions of Tomcat. We can help you migrate versions and optimize your Tomcat setup.
By leveraging OpenLogic experts, you can innovate more and save on costs associated with supporting open source technology.
This blog was originally published on September 5, 2012 and has been updated for accuracy and comprehensiveness.
Related Content
- Beginner's Guide to Tomcat Memory Configuration
- Tomcat Overview and Resource Collection
- Preparing for Your Next Tomcat Upgrade
- Tomcat Configuration Tips and Tricks
- 5 Apache Tomcat Performance Best Practices
- Tomcat SSL Proxy
- Ghostcat Vulnerability
- Tomcat 9: Key Features
- Apache Tomcat 10: Considerations for Enterprise Deployment
- Tomcat vs. TomEE: Comparing Specifications and Use Cases