Multiple applications inside a single container will pollute threads with wrong Time Zone information.
Running multiple applications in a single container that rely on the TimeZone.getDefault() method will cause problems where the time zone can not be reset inside the thread. For instance, if one application calls TimeZone.setDefault("GMT"), it will affect the TimeZone (or ZoneInfo) instance over the entire thread. If a second application is then run on that thread, it will pick up the default set by the previous container.
There is not much Tomcat since this particular problem lies in the JVM. With this said, there are couple of options, however:
1. Run each app on its own Tomcat instance
2. Write a valve/filter that resets the default timezone. Unfortunately there is not a way to divide the thread pool and assign them per application.
Option 1 would be the recommended and simple solution and use option 2 as the fallback.
Security Audits may identify issues with 500 errors, and require the stack traces to be suppressed.
By default when a 500 error (Internal Server Error) occurs in Tomcat it will display a full stack trace on the error page. This can give a hacker information about what technology is being used within the application. To control the error response, it is recommended to customize your own error reporting valve. The current error reporting valve is a good starting point and can be modified to meet your needs. To remove the stack trace element alone will mean removing two lines of code.
Here is the source to the current valve:
Files in the work and temp directories depend on timestamps to be overwritten.
If you deployed the web app using WAR file originally, then you need to either redeploy the entire WAR file or need to meet any of the conditions listed in the official Apache Tomcat documentation.
Your other two options are:
Tomcat 6.0.14 introduced stricter spec-compliant functionality for cookies and may cause issues integrating with older versions of Tomcat.
When parsing cookies among different versions of Tomcat, if your cookie contains a "." it could cause versions greater than Tomcat 6.0.14 to truncate the cookie.
Since these versions are spec-compliant, the primary recommendation would be to have all systems upgraded to the latest version of Tomcat so you are both complaint as well as up to date on bug fixes and vulnerabilities.
Since upgrading isn't always an option, you can try the following options to see if they help:
Determining the best configuration for concurrency is dependent upon the application running on Tomcat.
Because every application is so different, there are no general guidelines for how many instances you setup on different kinds of hardware, but there is a way to determine how your application will best run on your given hardware.
To determine what is the best config:
1. You need some sort of load test or measurement of performance
2. Start out with one instance, the reason for this is simplicity. Have this instance setup with maxThreads="400"
3. Run the load test