-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 John,
On 4/6/2009 6:50 PM, John Oliver wrote: > On Mon, Apr 06, 2009 at 06:08:54PM -0400, Christopher Schultz wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> John, >> >> On 4/6/2009 5:51 PM, John Oliver wrote: >>> RHEL 5.2, httpd-2.2.3-11.el5_1.3, tomcat5-5.5.23-0jpp.7.el5_2.1 >> 2.2.3 is pretty old... any chance of upgrading to 2.2.11? You're nearly >> 3 years out of sync with the state-of-the-art. > > Tell it to Red Hat... It's interesting how these distro maintainers act with regard to packages. IFAICT, their stance is that they spend a /long/ time vetting a particular package (let's say httpd 2.2.3) and then they go ahead and allow their customers to use it. Any security patches that come out for it will be applied, re-tested, and then released (that's why you see the "-11.el5_1.3" on the end of the official release number), but all other patches are ignored. Since it apparently takes so long to vet a new release, they don't bother to do it for every release... they just apply the security patches and consider it "stable". Unfortunately, big bug fixes that don't have anything to do with security (hey, mod_proxy_ajp is plenty secure because it doesn't allow communication!) don't make it into the distro. I know that Debian has different "branches" that you can follow depending on your level of paranoia about breaking things: security, stable, unstable, etc. Does Red Hat have anything like that? It's possible that you have (possibly unintentionally) stuck your Apache httpd version at a particular release level for fear of breaking something that is working. My sense is that a minor-version upgrade shouldn't break anything at all (unless there is some kind of regression)... just make sure you test everything before you put it into production. >> $ java -version > > [r...@mda-services ~]# java -version > java version "1.6.0_05" > Java(TM) SE Runtime Environment (build 1.6.0_05-b13) > Java HotSpot(TM) Server VM (build 10.0-b19, mixed mode) Good. The presence of the gcj should not interfere as long as the /real/ Java is the one being used by Tomcat. I suspect it is, but you can always check with a simple JSP or something that dumps out the system properties (System.getProperties().list(System.out) ought to do the trick). > The only config I'm aware of is /etc/httpd/conf.d/proxy_ajp.conf, which > consists of lines like: > > ProxyPass /GmmsL/ ajp://localhost:8009/GmmsL/ > > I just add another similar line for each app. Okay, that's mod_proxy_ajp alright. As Rainer mentioned, there have been a /lot/ of improvements to mod_proxy_ajp since your version was released. I recommend working with Red Hat on a solution. Maybe they'll do a custom build for you... you /are/ paying them for support, afterall :) >> I've had the JVM crash crash (for different issues) and I've run out of >> memory, but Tomcat has never failed me. The most likely reason for >> "server instability" is, sadly, your own application. We might be able >> to help with that, too. > > That would rock :-) Come on back when you've got this AJP thing worked out. If Tomcat stops responding, take a few thread dumps (send a SIGQUIT to the main Java process, or use 'jstack') a few seconds apart. One or two over a 20-30 second time period should be enough. This will dump a stack trace for all running threads to stdout (which can be redirected to a file if using jstack, or collected from catalina.out if using SIGQUIT). These will help a lot in determining what the problems might be. Good luck, - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAknbh3MACgkQ9CaO5/Lv0PC1PACgkyqz5z0Z2mi7Jh0xPjUPqpJG KDQAoJdAJ+gRwTNBR9Zxm+4KP15sKdUz =L/uN -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
