Should I upgrade to Tomcat8 from Tomcat 7

Question

My project is currently running on Tomcat 7. Should I go for upgrade to Tomcat 8? What are the pros and cons of doing that? is tomcat 8 better in terms of performance, memory utilization?

Answer 1

Since your project is already running on tomcat 7 i would recommend keeping the status quo for some more time. Not much data is available regarding tomcat 8 performance improvement. Some issues are reported on internet which is common for any new release of a product.

Tomcat 8 has better performance in concurrent environments.

From my experience with tomcat products most probably upgradation would not result in any significant performance unless you have a very resource intensive application. Please read below link before upgradation

http://events.linuxfoundation.org/sites/events/files/slides/2014-04-09-Migrating-to-Apache-Tomcat-8.pdf

Important changes

Java 1.7 ==> The first important change, is that Tomcat 8 requires now Java 7 or later in order to run, therefore if you are migrating from earlier Tomcat version, you should upgrade to Java 7

Specification Changes

Servlet 3.1 (JSR 340)
JSP 2.3 (JSR 245 maintenance release)
EL 3.0 (JSR 341)
WebSocket 1.0 (JSR 356)

Specification Changes: EL 3.0

Coercion of nulls to Number, Character or Boolean
- EL 2.2 and earlier (0, 0, false)
- EL 3.0 and later (null, null, null)
System property
– org.apache.el.parser.COERCE_TO_ZERO
– Set to true for EL 2.2 behaviour

Specification Changes: JSP 2.3

Minor changes to reflect the changes in EL 3.0
JSP 2.3
– Supported: GET, POST and HEAD
– Undefined: Everything else
 JSP 2.2 and earlier
– Undefined: Most implementations assumed all
 Tomcat only permits GET, POST and HEAD
– Protection against verb tampering

Specification Changes: WebSocket 1.0

Tomcat 7 initially shipped with a proprietary WebSocket API
- Tomcat 8 ships with a JSR 356 WebSocket implementation
– Also back-ported to Tomcat 7
- The proprietary WebSocket API is deprecated in Tomcat 7
- Applications using the proprietary API need to migrate
– Relatively simple
– https://svn.apache.org/r1424733

Specification Changes: Servlet 3.1

- Session ID changes by default on authentication
– Prevents session fixation

Tomcat Changes:

Connectors

Default connector has changed from BIO to NIO
– BIO is likely to be dropped for Tomcat 9
- Only BIO option not supported by NIO is irrelevant for NIO
– disableKeepAlivePercentage
- May notice different network / CPU loads
– More established, idle connections
– Marginally higher CPU load

Static Resources

Tomcat 7
– Aliases
– VirtualLoader
– VirtualDirContext
– JAR resources
– External repositories
- All variations on a theme
- Each implemented differently


Tomcat 8
– New WebResources implementation
▪ JAR resources
– External resources for class loader
- Completely new configuration
- Caching attributes removed from Context

Resources now defined by as:
– Pre-resources
– Main resources
– JAR resources
– Post-resources

Resources attributes:
– base
– internalPath
– webappMount
– readOnly

 Internal APIs

- Lots of changes
– Manager, Loader and Resources are now Context only
– Mapper moved from Connector to Service
– WebResources
- If you extend a Tomcat class, review the API docs

Database Connection Pools

- Tomcat 7 and earlier based on DBCP 1
- Tomcat 8 based on DBCP 2
- Better performance in concurrent environments
– Comparable to Tomcat’s JDBC pool
- There are some changes to configuration attributes
– Reflect consistency changes made in Commons Pool 2
- maxActive -> maxTotal
- maxWait -> maxWaitMillis
- Validation no longer requires a validation query
– Uses Connection.isValid()

Server Connectors

In terms of the server connectors, the default HTTP and AJP connector implementation has switched from the Java blocking IO implementation (BIO) to the Java non-blocking IO implementation (NIO). The older BIO may still be used but Servlet 3.1 and WebSocket 1.0 features that use non-blocking IO will then fallback to blocking IO instead which may cause unexpected application behavior.

Web application resources

The Resources element that is part of the configuration and represents all the resources available to the web application has been revised. Now it includes classes, JAR files, HTML, JSPs and any other files that contribute to the web application. Implementations are provided to use directories, JAR files and WARs as the source of these resources and the resources implementation may be extended to provide support for files stored in other forms such as in a database or a versioned repository.

Remote Debugging

When starting Tomcat 8 with the jpda option to enable remote debugging, Tomcat 8 listens on localhost:8000 by default. Earlier versions listened on *:8000. If required, this default can be overridden by setting the JPDA_ADDRESS environment variable in, for example, setenv.[bat|sh].

Changes in API

Whilst the Tomcat 8 internal API is broadly compatible with Tomcat 7 there have been many changes at the detail level and they are not binary compatible. Developers of custom components that interact with Tomcat's internals should review the JavaDoc for the relevant API.

Of particular note are:

The Manager, Loader and Resources have moved from Container to Context since Context is the only place they are used.

The Mapper has moved from the Connector to the Service since the Mapper is identical for all Connectors of a given Service.

There is a new Resources implementation,as we said, that merges Aliases, VirtualLoader, VirtualDirContext, JAR resources and external repositories into a single framework rather than a separate one for each feature.

Some links that provide more info about changes in tomcat 8 is given below

http://people.apache.org/~markt/presentations/2013-09-Apache-Tomcat8.pdf

https://tomcat.apache.org/tomcat-8.0-doc/changelog.html

Answer 2

Here's how to understand on your own when to upgrade. You can use this with any version of Tomcat, now or in the future, it does not just cover upgrading from Tomcat 7 to Tomcat 8.

Most changes to Tomcat when a major version is changed are upgrades to the servlet, JSP and JDK specifications that a particular version is built on. If you don't need the newer specifications for your application and the version you are using is not "archived" (Tomcat 7 is not archived as of this writing), you probably don't need to upgrade. http://tomcat.apache.org/whichversion.html covers how to make a selection.

In real world situations, your choice might be influenced by other factors as well, such as whether the version you want is supported by the package manager in your production distro. Or conversely, if your distro only has a specific version of Tomcat, you might upgrade because it saves significant time.

Remember that new features also mean the potential for new bugs. If you aren't using specifications of a new Tomcat version, do you want to take the chance of something breaking? Just because a version has the potential for higher performance does not mean it won't crash in your unique deployment environment. The best answer here, if you can afford it, is to deploy both versions behind a load balancer in case the new one does not work.

That said, there are always improvements in software. I suggest reading the release notes for releases of various versions of the major version you select to pick the best one for your own circumstances. https://tomcat.apache.org/tomcat-8.0-doc/RELEASE-NOTES.txt covers the 8.0 release, for instance.

Once you choose a major version, you generally want to use the latest version of it since bugs will get fixed over time.

Answer 3

See below new major features of tomcat 8. This will help in deciding whether to migrate if you need them.

Tomcat 8.0 release aligns with the Java EE 7 Specification. It supports:

• It supports Java Servlet 3.1
• Java Server Pages (JSP) 2.3
• Java Unified Expression Language (EL) 3.0
• Java WebSocket 1.0

Tomcat 8 can use the Apache Portable Runtime to provide superior scalability, performance, and better integration with native server technologies.

In terms of the server connectors, the default HTTP and AJP connector implementation has switched from the Java blocking IO implementation (BIO) to the Java non-blocking IO implementation (NIO)

Also please note, Tomcat 8 requires Java 7 or later in order to run, so only migrate if you are using at least Java 7 in your project.