It is late on a Friday afternoon, and your web application has stopped responding to requests. The server is still reachable, and the Apache Tomcat process is still running–there are no errors in the logs. You want to go home but you can’t until it is fixed. What do you do?
If your answer is “restart Tomcat and hope it stays up until Monday,” then this article is for you.
Rather than keeping your fingers crossed and hoping you don’t get an angry call from your boss over the weekend, this article will provide you with some simple steps you can take to diagnose the problem.
If the Tomcat process is running, then it must be doing something. The question is what is it doing when it should be responding to requests? The way to answer that question is with a thread dump–actually, a series of thread dumps. You need to take three thread dumps roughly 10 seconds apart and then compare them. I always compare them with a diff tool rather than by eye—a it is far too easy to miss subtle but important differences between the dumps.
How you generate a thread dump depends on your operating system and how you are running Tomcat. On Linux, FreeBSD, Solaris etc. use kill -3 to trigger a thread dump. On Windows use CTRL-BREAK if Tomcat is running in a console window. If Tomcat is running as a service, then the service wrapper should provide a way to trigger a thread dump. Commons Daemon (the service wrapper that ships with Tomcat) provides an option to trigger a thread dump via the system tray icon.
ApacheCon North America is almost concluding, and my experience this year has not disappointed. It’s been great to be able to meet up with lots of other project committers. Many committers make the trek to ApacheCon wherever it is in the world and, given that we normally work together just via the project mailing lists, it has been great to be able to discuss current issues and new ideas face to face. Of course, all of these discussions will be making their way (if they aren't there already) to the Tomcat dev mailing list so the everyone in the community can participate.
Personally, I have spent a great deal of my time in presentations. I have spoken about progress on Tomcat 8, delivered another session on clustering and two on security covering vulnerabilities and security response at the ASF. As always, slides are available from http://people.apache.org/~markt and there should be video and audio recordings available as well at some point. Most sessions were reasonably well attended and the conversation and questions flowed after the presentations. Here are some of the questions and answers I found most interesting:
SpringSource engineer and Apache Software Foundation's release manager for Apache Tomcat 7, Mark Thomas, reviews what is currently in Tomcat 7 and future plans.
This Apache Tomcat 7 update was originally delivered at the SpringSource S2G Forum Series in Amsterdam on May 26, 2011, by SpringSource engineer and the Apache Software Foundation's Apache Tomcat 7's release manager, Mark Thomas.
You have a few problems, the cause of them is not entirely clear.
One thing to bear in mind is this: when you're using Apache HTTPD in front of Tomcat, if you can get it working under normal HTTP then configuring HTTPS should be simple.
HTTP and HTTPS in Apache HTTPD are treated as separate VirtualHosts, so it should just be a case of ensuring that whatever configuration you've applied to the HTTP virtual host is also applied to the HTTPS host.
This can be achieved with ease, by placing all of the mod_jk or mod_proxy (in your case) configuration in an external file and using the 'include' mechanism.
The HTTP address you provide is using the port 8080, which Tomcat specifies as the default port for it's own HTTP connector - suggesting that you're not connecting via Apache HTTPD when you make that request.
The ProxyPass statements point both /abc and / to the same path, which is a subpath of the application /abc - this seems unusual. I'd expect to see the path http://server:8080/abc, without the '/implement' extension, this may be the source of some of the missing images.
In order to debug the problem, it would be better to start with a fresh configuration - discard whatever you have so far, or copy it to a backup.
The Fiddler or ieHttpHeader plugins for Internet Explorer will make it easier to examine which resources are, or are not being served correctly.
You will need to examine both the Apache HTTPD and Tomcat access logs to see which server is serving each request and check that the result is the expected one.
Configure the HTTP instance and test it thoroughly before attempting the HTTPS configuration.