Tomcatexpert.com contributors are all professional developers, most of whom perform contracts with other companies. Inevitably, when these pros get out in the field, other developers, hoping to learn some secret sauce, ask them about their preferred developer setup. So in the interest of sharing, we've pulled together a list of the top tools our Tomcatexpert.com contributors use in their daily dev environments.
Often times a developer or operations professional needs access to monitor a Tomcat instance for purposes of capacity planning, troubleshooting, and performance tuning. There are many tools available already for Tomcat, some of them open source, and others paid for. Some tools are simple and others are complex management suites.
There are comprehensive monitoring suites available that monitor and manage Tomcat, and do it well; however, there is always a benefit to being able to create your own custom Tomcat/application management tools. The first advantage is that you get exactly what you want out of your utility. In my example, I wanted to have a way to browse a Tomcat server’s Java Management Extensions’ MBeans with a hierarchical, bash-like navigation. This allows me to quickly find and diagnose problems with my Tomcat server or custom applications running within Tomcat, and is more precise than trending those MBeans over time using a more comprehensive monitoring suite. I liken it to purchasing a ready-made suit, or having one custom tailored to your exact specification. It just feels better sometimes, and other times it is not practical.
Many utilities will not provide the specific feature that you need. There are usually a host of open source or commercial utilities for anything that one goal any developer or operations professional may want to achieve; however, often times that utility will not integrate well into their existing infrastructure, or not play well with automated processes that are pre-existing in the enterprise. In such cases, a custom utility can come in handy. Writing your own tools from scratch is a quick solution to a specific problem, and cuts out a lot of the fat. For simple tools, the complexity risk argument just isn't there, and in the time it takes to write a simple custom application.
The short answer is that this is a myth. The longer answer is that back in the days of Tomcat 3 there was some truth to this depending on circumstances. However, for the versions of Tomcat in use today (5.5.x and 6.0.x) then there is no need to use httpd for purely performance reasons. Tomcat now supports the native/APR connector which uses the same native library (the Apache Portable Runtime—APR) as httpd for the low-level I/O and therefore can achieve similar performance to httpd. When serving static content there is ever so slightly more overhead when using Tomcat compared to httpd but the differences are so small they are unlikely to be noticeable in production systems.
If you research the httpd vs Tomcat performance issue, you will find a variety of load and performance benchmarks that show a range of results. An often quoted result shows that Tomcat's pure Java connector is consistently faster than httpd.
This particular result is the opposite of what is expected. httpd should be significantly faster than Tomcat's pure Java connector. This result is probably caused by the size of the file used. Tomcat caches small static files in memory by default and this will provide a significant performance improvement. httpd does not cache files in memory by default. This demonstrates quite nicely how the definition of the benchmark can have a significant impact on the results.
A default Apache Tomcat installation is secure but each installation environment is different and may have additional security requirements. This presentation will examine the security configuration options available in Apache Tomcat and SpringSource tc Server, when to use them (and when not to use them) and the threats they might help mitigate. The rationale behind having resource passwords (e.g. for database access) in clear text in server.xml will also be discussed.
Taking a service from running on an HTTP protocol on port 8080 to run on the HTTPS protocol on port 443 requires you to have a private key and signed certificate in place in order for the HTTPS connector to work. You will need to prepare the certificate keystore, edit the Tomcat configuration file and install the certificate on the target machine.
SSL (Secure Socket Layer) allows web browsers and web servers to communicate over a secure connection with both the browser and the server encrypting traffic before sending out data. Authentication is an important part of the SSL protocol and typically involves a server presenting a set of credentials to a visitor, or a “Certificate,” as proof the site is legitimate. With “Client Authentication,” the server asks for proof that the visitor is who they claim to be. Most SSL-enabled web servers do not request Client Authentication.
Secure Sockets Layer (SSL) is a common technology that web operations teams use to allow web browsers and web servers to communicate via a secured connection. Data is encrypted by by a two-way process, where both the server and browser are capable of encrypting, transmitting, and also decrypting messages sent by the other side prior to any processing.
An important component of the SSL protocol is how the server manages authentication. During the initial attempt to communicate with a web server over a secure connection, the secured server will present the web browser with a set of credentials, known as a Certificate of Authentication or CA, as validation that the site is who and what it claims to be.
This article will discuss how to use the popular open source implementation of the SSL protocol, OpenSSL, to create Certificates of Authentication (CAs) on Apache Tomcat.
There are a number of different http connectors that can be used with Tomcat. They are:
• Blocking IO
• Non-blocking IO
• Native/Apache Portable Runtime (APR)
The blocking IO connector is the default http connector. With this connector each request is handled by a dedicated thread (obtained from a pool) until the request is complete at which point the thread is returned to the pool to be re-used by another request.