On 27.12.2017 23:16, Eric Robinson wrote:
I mean A is java8 and tomcat8.. so make a C that is tomcat6 and java8
I don't think so. This is a requirement of the software company whose
application solution we use. They are requiring us to move to tomcat 8 with jdk
1.8. If we try to mix tomcat8 with jdk 1.6, supposedly we would have problems.
I guess all this is being driven by the need to switch to TLS 1.2. I'm not sure
if that would be a function of tomcat or java.
As you were looking for the reason of the increased footprint, this
would help you tremendously to get to the root cause, even if you don't
intend to use it in production. Assume that a similar behavior already
appears when you run tomcat6 with Java8 - in this case there might be
little reason to continue to dig in tomcat, and assume that it's the
Java implementation that caused your increased footprint.
Tomcat 8 with Java 6 won't work (apart from the outdated implementation)
as it requires at least Java7 (which is also outdated).
And then there's yet another aspect: The memory footprint increased way
below the price decrease for memory, so just adding this much memory
could be filed away as a reasonable assumption within 7.5 years (JDK
1.6.21 was released July 2010, I'm assuming that this is the age of the
hardware as well (because why would you have installed this version on
newer hardware, when newer releases existed)
I'm assuming that you have enough aspects to inspect - if you're really
interested in finding the root cause, you'll need to come up with more
specific measurements, e.g. profiler data, compare thread dumps and set
up Tomcat 6 with Java 8 to have a third reference point.
Olaf
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
