Apache Tomcat is a popular open source web application server. Here, we give an overview of Apache Tomcat 7, including:
Tomcat 7 is a version of Apache Tomcat released in 2011. More recent versions of Tomcat include Tomcat 8 and Tomcat 9.
Tomcat Is Just One Part of Your StackTomcat is just one part of your open source stack. But what about your other open source needs? Use our open source stack builder to build the ultimate stack to empower your organization.STACK BUILDER
Tomcat is just one part of your open source stack. But what about your other open source needs? Use our open source stack builder to build the ultimate stack to empower your organization.
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.
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.
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.
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:
This tells Tomcat that this application is designed to run on multiple nodes in this cluster.
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 188.8.131.52 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.
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.
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.
The Manager object controls session replication.
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.
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.:
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.
Tomcat 7 end of life is March 31, 2021 from Apache — but Apache isn't your only option for Tomcat 7 support.
You can get support for Tomcat 7 (and more recent versions) from OpenLogic. Our experts can help you configure Apache Tomcat, migrate versions, or simply provide longterm support that strengthens the security and reliability of the software for your business.
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 longterm 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.
TALK TO AN EXPERT
This blog was originally published on September 5, 2012 and has been updated for accuracy and comprehensiveness.
Enterprise Solutions Architect, OpenLogic by Perforce
Andrew has been working in the IT industry since 1996, ranging from hardware and networking to application development. Andrew’s #1 specialty is Apache Tomcat, and he is recognized in the Tomcat community as a subject matter expert, assisting the Tomcat open source project in many ways.