Should I upgrade to Tomcat8 from Tomcat 7
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
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
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