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