Tomcat
The reference is taken from Apache Tomcat 7 Essentials By: Tanuj Khare
Tomcat
Apache Tomcat is an open source Java-based web and servlet container, which is used to host Java-based applications. It was first developed for Jakarta Tomcat. Due to an increase in demand, it was later hosted as a separate project called Apache Tomcat, which is supported by The Apache Software Foundation. It was initially developed by James Duncan Davidson, a software architect at Sun Microsystems. He later helped make this project open source and played a key role in donating this project from Sun Microsystems to The Apache Software Foundation. Tomcat implements the Java Servlet and the JavaServer Pages (JSP) specifications from Sun Microsystems, and provides a “pure Java” HTTP web server environment for Java code to run.
Installation of Tomcat 7
In the previous section, we have discussed the new enhancements in Apache Tomcat 7. Now, it’s time to move on to the Tomcat installation.
How to download the Tomcat software
Perform the following steps to download the software:
Before we start the installation of Apache Tomcat 7 software, the first thing that comes to mind is where can you download the software from and also how much does the license cost? By default, Apache comes with Apache License, Version 2.0 ,which is compatible to GPL (General Public License). In simple terms, it is free of cost! For more information on licenses, you can visit http://www.apache.org/licenses/. Now, the second problem is how to download the software.
It is always recommended to download the software from its official site, http://tomcat.apache.org/download-70.cgi. By default, on http://tomcat.apache.org/, we get the latest stable version of Tomcat package and we have to download the package based on the operating system, where we want to install it.
Common problems and troubleshooting in installation
There are multiple issues which may arise during the installation of Tomcat 7. Let’s discuss these issues:
Error: Permission denied for the Java binary
Scenario 1: The Java installation is not working, while executing the Java binary.
[root@localhost opt]# ./jdk-6u24-linux-i586.bin
-bash: ./jdk-6u24-linux-i586.bin: Permission denied
Issue: The Java binary doesn’t have execute permissions with a specific user.
Fix: Change the permission to 0755 for ./jdk-6u24-linux-i586.bin using the following command:
chmod 0755 jdk-6u24-linux-i586.bin
The chmod 0755 file is equivalent to u=rwx (4+2+1),go=rx (4+1 & 4+1). The 0 specifies no special modes.
Error: Tomcat is not able to find JAVA_HOME
Performance tuning for Tomcat 7
Performance tuning plays a vital role to run a web application without downtime. Also, it helps in improving the performance of Tomcat while running the applications. Tuning of the Tomcat server may vary from application to application. Since every application has its own requirements, it is a very tricky task to tune Tomcat 7 for every application. In this topic, we will discuss tuning of various components of Tomcat, and how they are useful in the server performance. Before we start with the configuration changes, let us quickly discuss why we need to tune Tomcat.
Why we need performance tuning?
People always ask, why do we need to do performance tuning for Tomcat 7 when, by default, Tomcat 7 packages are customized for the production run.
How to start performance tuning
Performance tuning starts from the day the application deployment stage begins. One may ask, as the application is only in the development phase, why do we need to do performance tuning now?
At the time of the application development, we are in the state to define the architecture of the application, how the application is going to perform in reality, and how many resources are required for an application. There are no predefined steps for performance tuning. But there are certain thumb rules which all administrators should follow for performance tuning.
The following figure shows the process flow for performance tuning:
Tomcat components tuning
In Tomcat 7, you can do many configurations to improve the server performance, threads tuning, port customization, and JVM tuning. Let’s quickly discuss the major components of Tomcat 7 which are important for performance improvement.
Types of connectors for Tomcat 7
Connectors can be defined as a point of intersection where requests are accepted and responses are returned. There are three types of connectors used in Tomcat 7, as shown in the following figure. These connectors are used according to different application requirements. Let’s discuss the usability of each connector:
Java HTTP Connector
The Java HTTP Connector is based on the HTTP Protocol, which supports only the HTTP/1.1 protocol. It makes the Tomcat server act as a standalone web server and also enables the functionality to host the JSP/servlet.
JVM tuning
Before we start with JVM tuning, we should note that there are various vendors available in the market for JVM. Based on the application requirement, we should select the JDK from the vendor.
Sun JDK is widely used in the IT industries.
Why do we need to tune the JDK for Tomcat?
Tomcat 7 comes with a heap size of 256 MB. Applications today need a large memory to run. In order to run the application, we have to tune the JVM parameter for Tomcat 7. Let’s quickly discuss the default JVM configurations for Tomcat. The following steps describe the method to find out the Tomcat Process ID (PID) and memory values as shown in the next screenshot:
Run the following command on the terminal in Linux:
ps -ef |grep java
OS tuning
Every OS has its own prerequisites to run Tomcat 7 and the system has to be tuned based on the application’s requirement, but there are some similarities between each OS. Let’s discuss the common module used for optimization of Tomcat 7 for every OS. The OS plays a vital role for increasing the performance. Depending on the hardware, the application’s performance will increase or decrease. Some of the points which are very much useful for the application are:
Performance characteristics of the 64 bit versus 32 bit VM: The benefits of using 64 bit VMs are being able to address larger amounts of memory, which comes with a small performance loss in 64 bit VMs versus running the same application on a 32 bit VM. You can allocate more than 4 GB JVM for a memory-intensive application.
Integration of Tomcat with the Apache Web Server
The Apache HTTP server is one of the most widely used frontend web servers across the IT industry. This project was open sourced in 1995 and is owned by The Apache Software Foundation.
This chapter is very useful for the web administrator who works on enterprise-level web integration. It gives a very good idea about how integration is implemented in IT organizations. So, if you are thinking of enhancing your career in enterprise-level integrations of applications, then read this chapter carefully.
In this chapter, we will discuss the following topics:
The Apache HTTP installation
The various modules of Apache
Integration of Apache with Tomcat 7
How IT industry environments are set up
User request flow (web/application level)
Before we discuss the installation of Apache, let’s discuss a high-level overview of how the request flows from the web and application server for an application in IT industries. The following figure shows the process flow for a user request, in a web application. The step-by-step involvement of each component is as follows:
The user hits the URL in the browser and the request goes to the HTTP server instead of Tomcat.
The HTTP server accepts the request and redirects it to Tomcat for business logic processing.
Tomcat internally contacts the database server to fetch the data, and sends the response back to the user through the same channel of request:
Why the Apache HTTP server
The Apache HTTP server is one of the most successful and common web servers used in IT industries. The reason being that it is supported by open source communities. In IT industries, the Apache HTTP server is heavily used as a frontend web server for the following reasons:
Efficiently serves static content: Static content such as images, JS, CSS, and HTML files are more efficiently served by the HTTP server in a heavy user environment. Tomcat is also capable, but it increases the response time.
Increase the speed by 10 percent: As compared to Tomcat, Apache serves static content 10 percent more efficiently. Integration of Apache is very helpful in the scenario of a high user load.
Clustering: Apache is one of the most cost-effective and stable solutions to connect multiple instances of Tomcat. The biggest advantage of this feature is that the application will be online in case one of the instances goes down. Also, during deployment, we can deploy the code on one instance while the other instance is still online, serving requests to users. In simple terms, there is no downtime for the application.
Installation of the Apache HTTP
The Apache installation can be done using various methods, based on the requirement of the infrastructure. For example, if you want to run multiple Apache instances on a single machine, then the Source installation will be used. There are mainly three types of installations done in various web environments:
Source
Binary
RPM/exe
Source is preferred by web administrators, as it can be customized based on system requirements.
Apache HTTP installation on Windows
In this topic, we will discuss the installation of the Apache HTTP as a service. The installation of the Apache HTTP server on the Windows platform is quite simple. Following are the steps to be performed:
The Apache HTTP server can be downloaded from various different sites, but it is always recommended to download it from its official site http://httpd.apache.org/download.cgi. On this site, you can find the stable and beta release details. Download the latest Win32 Binary without crypto (no mod_ssl) (MSI Installer) given in the website. Click on httpd-2.2.X-win32-x86-no_ssl.msi to begin the download. Here 2.2 is the major version and X is the minor version, which changes almost every month. The following screenshot shows the different versions available for the download:
Apache Jserv protocol
This protocol was mainly developed to transfer data over the network in binary format instead of plain text. It uses TCP and a packet-based protocol, hence, increasing the performance of the web servers. Another informational point is that decryption of requests is done on the web server end so that the application server doesn’t have a high load.
If you are using AJP, the network traffic is reduced, as the tariff passes over the TCP protocol.
mod_jk and mod_proxy are based on the AJP protocol. They are also helpful in transmitting a high content response over the browser.
If we use the latest version of mod_jk for integration of Apache and Tomcat, then we can store the response header of 64k in the web browsers. This process is very useful in the case of SSO enabled applications or storing Java session values in the browser.
Securing Tomcat 7
The Internet has created a revolution in the 21st century; it provides us the capability of collecting information in seconds, whereas it would have taken months to collect the information previously. This has also raised security concerns for information privacy and has created the requirement of securing information over the Internet.
Everyday, new technologies are emerging to improve Internet usage for applications. With these technologies in the market, it becomes a tricky job for hackers and other communities to access secure information.
In this chapter, we will discuss the following topics:
Tomcat security permissions
Catalina properties
SSL implementation on Tomcat 7
Tomcat Manager
The security being a major concern for IT companies, a separate department for IT security administration is created in every company. Their major responsibility is to make sure that there are no vulnerabilities in terms of the networks, web, and OS infrastructure.
We should download Tomcat from the Tomcat website or any secure, known host. There is a chance that malicious software is shipped with Tomcat if we download it from an unknown source. Once the download is complete, verify the integrity of Tomcat using MD5/PGP. In case of Linux, the MD5 can be verified with Open Specification for Pretty Good Privacy (OpenPGP). This is a must in the process of production systems.
Tomcat security permissions
Apache Tomcat comes with good security-enabled options, but every environment has its own requirement for security, based on the usage of the application. For example, banking sites require a high level of security, on the other hand, user-based applications require little security.
In Tomcat 7, the default permission is configured in TOMCAT_HOME/Conf directory. The security is a collective effort of four files which make the system. Let’s discuss about each file and their functionality.
catalina.properties
This file contains information related to the access of the package, package definition, common loader, shared loader, and a list of JAR files, which are not necessary to be scanned at the startup of Tomcat. It helps in improving the performance, as adding too many JAR files to the skip list improves memory consumption. If you want to add any common JAR, you have to define it under catalina.properties.
Enabling Tomcat Manager
By default, the Tomcat Manager is disabled in Tomcat 7. It is a very powerful tool, but if it goes to the wrong hands, then it can create a problem for the system administrator or the application administrator. So it’s very important that you enable Tomcat Manager with proper security.
How to enable the Tomcat Manager
For enabling the Manager, we have to edit tomcat-users.xml, which is present in TOMCAT_HOME/conf. You will see that Tomcat users are commented out, as shown in the following screenshot:
How to enable the Tomcat Manager
Uncomment the user and save the file, followed by reloading Apache Tomcat 7, as shown in the following screenshot:
How to enable the Tomcat Manager
If you enable Tomcat Manager in a production environment, make sure it can be accessed only from the internal environment and not the DMZ.
Securing Tomcat 7 for production
In this topic, we will discuss the best practices used for securing Tomcat 7. Securing Tomcat does not mean only Tomcat, it includes both Tomcat configurations and other infrastructure configurations. Let’s first start with the Tomcat configurations.
Tomcat settings
There are different methods of securing Tomcat 7 and these come into picture based on the application’s requirement and the security policy used by an IT organization.
Every organization has their own security policies and the IT administrator follows them while implementing the security in Tomcat.
In Tomcat 7, there are different configurations, which need to be changed or enabled in order to secure Tomcat for the external environment. Let’s discuss each configuration and their usage for a real-time environment.
SSL configuration on Tomcat 7
Secure Socket Layer (SSL) is another way of securing data communication. It is a cryptographic protocol, in which data travels through a secure channel. The server sends a secure key to the client browser, the client browser decrypts it and a handshake takes place between the server and the client or we can say it’s a two-way handshake over the secure layer.
When is SSL required for Tomcat?
SSL will be more efficient if you are using Tomcat as a frontend server. In case you are using Apache or IIS, then it’s recommended to install SSL on Apache or the IIS server.
Types of SSL certificates
Before we go ahead and install SSL, let’s discuss the two types of SSL certificates, which are explained as follows:
Logging in Tomcat 7
Logging services play a vital role in the life of the administrator and developer to manage the application from the phase of development to production issues. It’s the logging services that help you to find the actual problem in the web application. Also, it plays an essential role in performance tuning for many applications.
In this chapter, we will discuss:
Logging services in Tomcat 7
JULI
Log4j
Log level
Valve component
Analysis of logs
JULI
Previous versions of Tomcat (until 5.x) use Apache common logging services for generating logs. A major disadvantage with this logging mechanism is that it can handle only a single JVM configuration and it makes it difficult to configure separate logging for each class loader for independent applications. In order to resolve this issue, Tomcat developers have introduced a separate API for the Tomcat 6 version, that comes with the capability of capturing each class loader activity in the Tomcat logs. It is based on the java.util.logging framework.
By default, Tomcat 7 uses its own Java logging API to implement logging services. This is also called JULI. This API can be found in TOMCAT_HOME/bin of the Tomcat 7 directory structures (tomcat-juli.jar). The following screenshot shows the directory structure of the bin directory where tomcat-juli.jar is placed. JULI also provides the feature for custom logging for each web application, and it also supports private per-application logging configurations. With the enhanced feature of separate class loader logging, it also helps in detecting memory issues while unloading the classes at runtime.
Loggers, appenders, and layouts
There are some important components of logging which we use at the time of implementing the logging mechanism for applications. Each term has its individual importance in tracking the events of the application. Let’s discuss each term individually to find out their usage:
Loggers: It can be defined as the logical name for the log file. This logical name is written in the application code. We can configure an independent logger for each application.
Appenders: The process of generating logs is handled by appenders. There are many types of appenders, such as FileAppender, ConsoleAppender, SocketAppender, and so on, which are available in log4j. The following are some examples of appenders for log4j:
log4j.appender.CATALINA=org.apache.log4j.DailyRollingFileAppender
log4j.appender.CATALINA.File=${catalina.base}/logs/catalina.out
log4j.appender.CATALINA.Append=true
log4j.appender.CATALINA.Encoding=UTF-8
The previous four lines of appender define the DailyRollingFileAppender in log4j, where the filename is catalina.out. These logs will have UTF-8 encoding enabled.
If log4j.appender.CATALINA.append=false, then logs will not get updated in the log files.
# Roll-over the log once per day
log4j.appender.CATALINA.DatePattern=’.’dd-MM-yyyy’.log’
log4j.appender.CATALINA.layout = org.apache.log4j.PatternLayout
log4j.appender.CATALINA.layout.ConversionPattern = %d [%t] %-5p %c- %m%n
The previous three lines of code show the roll-over of the log once per day.
Types of logging in Tomcat 7
We can enable logging in Tomcat 7 in different ways, based on the requirement. There are a total of five types of logging that we can configure in Tomcat, such as application, server, console, and so on. The following figure shows the different types of logging for Tomcat 7. These methods are used in combination with each other based on the environment needs. For example, if you have issues where Tomcat services are not displayed, then the console logs are very helpful to identify the issue, as we can verify the real-time boot sequence. Let’s discuss each logging method briefly:
Application log
These logs are used to capture the application event while running the application transaction. These logs are very useful in order to identify the application level issues. For example, suppose your application performance is slow on a particular transition, then the details of that transition can only be traced in the application log. The biggest advantage of application logs is we can configure separate log levels and log files for each application, making it very easy for the administrators to troubleshoot the application.
Types of log levels in Tomcat 7
There are seven levels defined for Tomcat logging services (JULI). They can be set based on the application’s requirement. The following figure shows the sequence of the log levels for JULI:
Every log level in JULI has its own functionality. The following table shows the functionality of each log level in JULI:
Log4j
Log4j is the project run by The Apache Software Foundation. This project helps in enabling the logs at the various levels of the server and application.
The major advantage of log4j is manageability. It provides the developer a freedom to change the log level at the configuration file level. Also, you can enable/disable logs at the configuration level, so there is no need to change the code. We can customize the log pattern based on the application, separately. Log4j has six log levels. The following figure shows the different types of log levels in log4j:
Values for Tomcat 7
Values are defined as identifiers which change the pattern of the string in the log. Suppose you want to know the IP address of a remote host, which has accessed the website, then you add the combination of the following values mentioned in the log appenders. For example, let’s customize the access logs for Tomcat 7. By default, access logs for Tomcat are defined as follows:
We want to change the log pattern to show the time taken to process the request. We have to add the %T in the patterns. The changed code is shown as follows:
Troubleshooting in Tomcat
Every day, IT administrators face new problems with servers in the production environment. Administrators have to troubleshoot these issues to make sure that the applications work perfectly.
Troubleshooting is an art of solving critical issues in the environment. It comes with experience and the number of issues you have come across in your career. But there is a set of rules for fixing the issues. We will discuss the real-time issues, which may occur in the production environment. We will also discuss tips and tricks for resolving issues.
In this chapter, we will discuss:
Common issues
Third-party tools for thread dump analysis
Tomcat specific issues related to the OS, JVM, and database
How to troubleshoot a proble
Common problem areas for web administrators
Web administrators always find issues with applications, not due to server failure of the Tomcat server, but because applications start malfunctioning due to other components as well. The following figure shows different components for a typical middleware environment:
let’s briefly discuss the issues encountered by web administrators in real-time production support:
Application: These issues occur when an application doesn’t work correctly due to reasons such as class loader conflicts, application deployment conflicts, configuration parameters missing, and so on.
Database: Database issues are very critical for the web administrator. It is very difficult to find the issues related to the DB. Some of them are; JNDI not found, broken pipe errors, and so on.
How to obtain a thread dump in Tomcat 7
The thread dump is a way through which we can determine the application-level thread status for any Java process. There are many ways to obtain a thread dump in Tomcat; here we will discuss two different ways which are widely used in the IT environment.
Thread dump using Kill command
This command generates and redirects the thread dump in catalina.out log. But, the limitation to this command is it works in a non-DOS environment such as Linux, Unix, and so on.
Kill -3 java process id
For example:
Kill -3 10638
Web server benchmarking
Now we know how to troubleshoot problems and find potential solutions in the systems. There is one more point left to discuss, Web server benchmarking. Without discussing this topic, troubleshooting in Tomcat 7 cannot be marked as complete. It’s a process through which we gauge the performance of a web server, also known as Load testing. In this process, we run the server virtually on a heavy load and estimate the real-time performance. This process is very useful if we want to do capacity planning for the web server. There are many tools available for performing load testing on the server such as ApacheBench (ab), JMeter, LoadRunner, OpenSTA, and so on. Let’s discuss the commonly used open source tools such as ApacheBench and JMeter. If we do the benchmarking of the server before the go live stage, then we will face less issues in production support. Also, it helps in improving the performance and designing the scalable environment architecture
Monitoring and Management of Tomcat 7
Monitoring plays a vital role in an IT administrator’s life. It makes the life of a web/infrastructure engineer predictable. When I started my career in web infrastructure support, I always wondered, how does my boss know that a process is 90 percent utilized for a particular system or how does he know that a particular process will die after about 90 minutes from now, without logging into the application? Later, I found out that they have set up a monitoring system using various third-party tools available in the market for servers and application monitoring.
In this chapter, we will discuss:
How to monitor Tomcat 7
Management of applications using the Tomcat Manager
A third-party utility used for monitoring Tomcat 7
Different ways of monitoring
In today’s world, with increasing infrastructure, it becomes very difficult for administrators to manage servers. In order to identify the issue beforehand, and to minimize the downtime, monitors are configured on the system. We can configure multi-level monitoring on the systems, based on the infrastructure requirements for example, the OS, Web, Application, and Database level servers and individual application level. There are different ways of configuring multi-level monitoring. The following figure shows different ways to configure monitoring for any infrastructure:
Monitoring can be mainly done in three ways on a system, which are as follows:
Third-party tools
Monitoring setups are configured using third-party tools present in the market, such as Wily, SiteScope, Nagios, and so on.
Monitoring setup for a web application and database server
In the previous section, we have discussed the types of monitors, but still we don’t know which monitors are configured on these systems. Let’s prepare a table for the different infrastructure system monitors and why they are configured. The following table shows the basic monitors, which are normally configured for web application and database servers:
Tomcat Manager in Tomcat 7
The Tomcat Manager is a default tool for managing operations of Apache Tomcat 7. It provides freedom to the IT administrators to remotely manage the application and monitor the systems. Following are the advantages of the Tomcat Manager:
Allow remote deploy, rollback, start, and stop features for the administrator.
Provide detailed monitoring status for the application and server.
Administrators need not stay in the office 24×7. In case of any issues, he/she can log in to the Tomcat Manager to resolve the issue. In short, we can say remote administration of Tomcat becomes very easy for administrators.
It’s not recommended to open the Tomcat Manager from the Internet. In case you have to do so, then we have to enforce strong security policies on Tomcat 7 or we can configure the Virtual Private Network (VPN) for the administrators.
Monitoring in Tomcat 7
Monitoring in Tomcat 7 can be done using the Tomcat Manager. By default, the Tomcat Manager provides the status of the server with a detailed description of requests and their status. This information is very useful to administrators at the time of troubleshooting. Apart from this, the administrator need not log in to the machine for collecting this information. It takes a minimum of 30 minutes to collect the entire information of the application, if you are checking the server status manually, but using the Tomcat Manager, you are getting it online. That’s truly amazing and a great help for IT administrators.
Let’s discuss the various components used for monitoring that are available in the Tomcat Manager.
JConsole configuration on Tomcat 7
JConsole is one of the best monitoring utilities that comes with JDK 1.5 or later. The full form of the JConsole is the Java Monitoring and Management Console. It’s a graphical tool, which gives complete details of the application and server performance. It gives us the following information about the application hosted in Tomcat 7:
Detect low memory
Enable or disable the GC and class loading verbose tracing
Detect deadlocks
Control the log level of any loggers in an application
Access the OS resources—Sun’s platform extension
Manage an application’s Managed Beans (MBeans)
Remote JMX enabling
In order to use the JConsole for Tomcat 7 monitoring, we have to enable the Java Management Extension (JMX) on Tomcat 7. By doing this, we can monitor the Tomcat 7 server details from our desktop machine also, or in simple terms, we can monitor the server status remotely without logging into the server machine. It gives great flexibility to the administrator to work from any location and troubleshoot the problem. In order to enable it in Tomcat 7, we have to add the CATALINA_OPTS parameter in catalina.sh. By default, the following values are added to enable the details:
Clustering in Tomcat 7
I would like to start this topic with a story. There were two teams; A and B, in an IT organization, managing different systems. Both teams consisted of highly qualified experts in middleware. One day, the CEO of that organization called a meeting for both teams, stating that they had to manage two different middleware environments, one middleware environment was individually assigned to teams A and B. Each team had to follow their own approaches to fix the environmental issues. After 3 months, each client performed a process review and the results surprised the higher management. Team A had maintained 50 percent uptime for the application and Team B had maintained 99 percent uptime for the application hosted in their environment.
What is a cluster?
The cluster is a group of servers or computers connected together, which may perform similar functionality in the system. These systems are normally connected to each other through high speed Ethernet. Cluster systems are used where quick processing or system availability is required. Some of the examples where clusters are highly used are the financial sector, banking, security areas, and so on. The following figure shows the J2EE containers clustered in the environment:
Cluster topology varies from environment to environment, based on the application requirements.
Benefits of clustering
There are many advantages of clustering in a middleware environment. It also depends on which cluster techniques we are using. We will discuss the various advantages of clustering:
Clustering architecture
In this topic, we will discuss the various architectures of clustering used by IT industries. These architectures may vary on each implementation, depending on the application and business requirements. There are basically two types of clustering architectures implemented in a real-time IT infrastructure:
Vertical clustering
Horizontal clustering
By default, Apache Tomcat 7 supports both horizontal and vertical clustering. In the next section, we will discuss the implementation of both types of clustering in Apache Tomcat 7. Before that, let’s discuss clustering architectures, where they can be implemented, and their advantages.
Vertical clustering
Vertical clustering consists of a single hardware with multiple instances running, using shared resources from the system. This kind of setup is mainly done in development and quality systems for the developer to test the functionality of the application. Also, vertical clustering can be implemented in production in certain cases, where there is a resource crunch for the hardware. It uses the concept of a shared resource such as CPU, RAM, and so on. The following figure shows the pictorial presentation of vertical clustering:
Vertical clustering in Apache Tomcat 7
In the previous topics, we have discussed the different types of cluster architecture, supported by Apache Tomcat 7. It’s time to take a real-time challenge to implement clustering. Let’s start with vertical clustering.
For vertical clustering, we have to configure at least two instances of Apache Tomcat and the complete process consists of three stages. Let’s discuss and implement the steps for vertical cluster in Tomcat 7:
Installation of the Tomcat instance.
Configuration of the cluster.
Apache HTTP web server configuration for the vertical cluster.
Horizontal clustering in Apache Tomcat 7
For horizontal clustering, we have to configure at least two instances of Apache Tomcat on two different physical or virtual systems. These physical machines can be on the same physical network. It also helps in providing a high-speed bandwidth to the system.
If you want to configure clustering on different networks, then you have to open the firewall between the two networks for the AJP port and the clustering port.
There are prerequisites for configuring horizontal clustering. The following are the details:
Time sync between the two servers
Proper network connectivity between the two servers
Firewall ports between the two servers (if you are connecting from a different network)
In order to configure horizontal clustering, you have to perform the following steps:
Testing of the clustered instance
To perform cluster testing, we are going to take you through a sequence of events. In the following event, we only plan to use two Tomcat instances—tomcatnode1 and tomcatnode2. We will cover the following sequence of events:
Start tomcatnode1.
Start tomcatnode2 (wait for node 1 to start completely).
Node 1 crashes.
Node 2 takes over the user session of node 1 to node 2.
Start node 1 (wait for node 1 to start completely).
Node 2 and node 1 are in running state.
Now we have a good scenario with us, we will walk through how the entire process works:
Start instance 1: tomcatnode1 starts up using the standard startup sequence. When the host object is created, a cluster object is associated with it. Tomcat asks the cluster class (in this case SimpleTcpCluster) to create a manager for the cluster and the cluster class will start up a membership service.
The membership service is a mechanism in the cluster instance through the cluster domain, which adds the member node in the cluster. In simple terms, it is a service through which members are able to join the cluster.
Monitoring of Tomcat clustering
Once the cluster is up and working, the next stage is to set up the monitoring of the clustering. This can be done in the following ways:
Various monitoring tools
Scripts
Manual
Following are the steps to manually monitor the clusters:
Check the Tomcat process using the following command:
root@localhost bin]# ps -ef |grep java
Check the logs to verify the connectivity of the cluster.
Verify the URL for both cluster members.
Tomcat Upgrade
Technological changes and innovations happen at a very rapid pace. In order to accommodate the current technology requirements and serve the user with the latest technology, an upgrade of the systems is needed. The new version of the systems comes with the latest features and bug fixes, making them more stable and reliable.
In this chapter, we will discuss:
The life cycle of the upgrade process
Best practices followed by the IT industry
How to upgrade Tomcat 6 to Tomcat 7
Every organization follows their process to upgrade the servers, based on the criticality of the system. Normally, evaluation of a product is done by the Technical Architect. Based on the application’s criticality, the architect defines the architecture, which needs to be followed to upgrade the application. Upgrades in production can be done only after a successful upgrade on the development server(s).
Different types of environment
Development environment
It can be defined as the combination of software and hardware, which is required for a team to build the code and deploy it. In simple words, it is a complete package required to build the code and deploy it.
The following points describe why we need a development environment and its advantages:
Consolidation: For example, by looking at the infrastructure needs of the development environment as a whole, you might find that you only need a single web/application server to deploy the application.
Life cycle of the upgrade
In this topic, we will discuss the various steps performed during the upgrade. The life cycle consists of the end-to-end processes involved in the upgrade. Normally, upgrades are initiated from the development environment followed by the QA/stage/production environment. The following screenshot shows the basic sequence of steps followed in the upgrade for any system in the IT industry:
Analysis of Enhanced Features and Business Requirements: This step plays a very crucial role in the upgrade process. In this process, the standing committee (technical architect, business owner, and functional owner) decides which features are essential for the new version and how they are useful in supporting the business requirement.
Tomcat upgrade from 6 to 7
Until now, we have discussed various theoretical processes of the upgrade. Now it’s time to have some fun, which every administrator wants in his/her career.
In this topic, we will discuss the most waited topic of the book, that is the Tomcat upgrade. It’s always a wish for the web administrator to perform the upgrade from its previous major version to the new version. It also changes the perception of the administrator from day-to-day maintenance issues to the architecture-level integration. If you are involved in the upgrade activity for the product, then you are the first person in the organization who is working on that product, which gives you better visibility among other people. But before performing the upgrade, let’s discuss what new features/updates are offered by Tomcat 7 as compared to Tomcat 6. Following are the features:
ITIL process implementation
Until now, we have discussed the technical process of Tomcat and its configuration.Now it’s time to understand the Information Technology Infrastructure Library (ITIL) process followed during the upgrade process and its use in different sections of the upgrade, based on the features and implementation methods.
Availability management
It can be defined as the process which allows the organization to make sure its services support at minimal cost to the environment. It consists of the following features:
Reliability: It’s a process through which IT components are measured, based on the Statement of Work (SOW).
Maintainability: It’s a process through which we manage the entire system without any unplanned downtime.
Advanced Configuration for Apache Tomcat 7
In the previous chapters, we have discussed various topics for Tomcat 7 such as clustering, load balancing and so on. But, in practice, there are some different configurations needed to perform on the system, apart from the Tomcat internal configuration, in order to manage the systems. In this chapter, we will discuss the advanced topics for Tomcat 7, used in real-world industries, to create the web infrastructure and support multiple web applications.
In this chapter, we will discuss the following topics:
Virtual hosting
Running multiple applications on a single Tomcat server
Multiple Tomcat environments such as Development, QA, Stage, and Production
Tuning cache
Optimization of Tomcat
Virtual hosting
It’s a method through which you can host multiple domain names on the same web server or on a single IP. The concept is called shared hosting, where one server is used to host multiple websites. For example, if you want to host abc.com and xyz.com, and later you want to add one more website on the same web server, that can be achieved by virtual hosting. Basically, there are two types of virtual hosting:
Name-based virtual hosting
IP-based virtual hosting
Name-based virtual hosting
It’s a method through which you can host multiple domains on a single IP. It uses the concept of shared services. In practice, web hosting companies follow this approach to host multiple sites for a low cost. For example, we have multiple sites such as www.abc.com,www.xyz.com, and www.xzy.com, and we want to configure it on the single web server using a single IP, then name-based virtual hosting is used. Following are the advantages of name-based virtual hosting:
Virtual hosting in Tomcat 7
Tomcat 7 supports name-based virtual hosting. This approach is very useful in hosting multiple web applications on the single instance of Tomcat 7. It also gives more privileges to the administrator to separate the applications from each other and their access control restrictions. You cannot understand the real concept of virtual hosting unless you implement it. So why wait, let’s do the real-life implementation for virtual hosting in Tomcat 7.
For example, if you want to host the previously mentioned sites on the web server, then the DNS will be configured in the following manner. Let us assume the web server name is webserver1.yxz.com and is hosted on the IP 192.168.0.1. To implement the previous scenario, the following steps need to be performed:
Hostname aliases
There is one more important feature that comes with Tomcat 7 called Host name aliases. It’s a very good feature that gives freedom to the administrator for multiple sites on the same network
For example, if you have a website which needs to be accessed through a subdomain by different users, then host aliases are created. It’s also called Sub domain aliases for the main domain. It is not possible to implement aliases in the previous versions of Tomcat. In case we want to implement aliases for any website, we have to use Apache, IIS, or a separate web server before Tomcat as a front-end server.
The following mentioned code describes how to set the alias for a particular site:
Multiple applications hosting on a single Tomcat 7 instance
Once we are done with virtual hosting, a few potential problems may arise such as multiple application hosting, security, and deployment of multiple applications on a single instance of Tomcat 7. Configuration of multiple domains on one single instance of Tomcat 7 is a bit tricky. If we give the applications one document root, then all applications can be accessed by all developers. The solution is to implement a separate document root for each domain. This way, we can implement a separate security on each application that is hosted in the Tomcat instance. Let us implement the solution by creating multiple document roots in Tomcat 7. To do so, we have to edit the server.xml to enable multiple document roots in the server, as shown in the following code snippet:
Multiple Tomcat environments—Development/QA/Stage/Production
Information technology organizations follow a set of environments to manage their applications. These environments are based on their functionality and usage. Support available for any environment depends on the environment’s functionality. Based on the functionality, the production environment has a high priority and development the least priority, as shown in the following figure:
The following table compares the different environments and their functionalities with respect to different tasks performed during creation and management of the web infrastructure:
Tuning cache
When we are running multiple applications on Tomcat 7, it is always recommended to utilize the resource correctly. In order to do so, we need to optimize the tuning parameter. Every time the server receives a request, it consumes the amount of CPU and memory in the system. In order to resolve this problem, we generate cache on the server from the first request. One of the best examples used for caching in major web hosting organizations is to generate cache for the static content.
The following code shows the configuration for adding Expires and Cache-Control: max-age= headers to images, CSS, and JavaScript. This code is added in web.xml, which is present in TOMCAT_HOME/CONF.
Recent Comments