Tomcat is more than enough to deploy most of the mid-end web applications without any problem but for the high-end applications which require high scalability and high availability, which might need some tune-ups with the support of expertise in this regard. Otherwise, you may realize numerous performance issues, memory leaks, server crashes etc.
The benefits outweigh the costs, and the ability to spin up a full cluster deployment for our internal applications on demand has been a game changer. We are able to leverage our engineers' core talents as J2EE developers without them concerning themselves with the infrastructure machinery of managing a highly available fault-tolerant server.
tomcat is just part of the J2EE specification implementation, majorly focusing on the servlet (front-end) part. If you requires the full J2ee stack, like EJB support, you need consider other containers like Weblogic
tomcat's cluster level support is very limited
tomcat's admin/configuration is not so intuitive, and default logging needs a lot of improvement
When we use the versions of GlassFish Server that were just released to the market, it causes bugs to appear. While there are workarounds to solve them in most cases, the amount of time to solve them is significant. Therefore, I would advise waiting for it to be a little more stable and for a few months to pass before proceeding to an update of a productive environment.
Tomcat has a very rich API set which allows us to implement our automation script to trigger the deployment, configure, stop and start Tomcat from the command line. In our projects, we embedded Tomcat in our Eclipse in all of the developer's machines so they could quickly verify their code with little effort, Azure Webapp has strong support for Tomcat so we could move our application to Azure cloud very easy. One drawback is Tomcat UI quite poorly features but we almost do not use it.
Tomcat doesn't have a built-in watchdog that ensures restart upon failure, so you have to provide it externally. A very good solution is java service wrapper. The community edition is able to restart Tomcat upon out of memories exceptions.
Tomcat support to customize memory used and allow us to define the Connection pool and thread pool to increase system performance and availability, Tomcat server itself consume very little memory and almost no footprint. We use Tomcat in our production environment which has up to thousands of concurrent users and it is stable and provides a quick response.
Commercial application servers are available that support enterprise application needs, but many times this is overkill for most web applications running in the cloud, particularly for independent software vendors. The capabilities and management tools provided with these applications are superior to Tomcat, but most times unnecessary for the vast majority of web applications developed in Java.
Tomcat is a more lightweight container in comparison to Oracle's Glassfish server and has wider adaptability in development for local testing. Glassfish however, as an enterprise product can offer better after sales service to clients.
It has simplified administration efforts, thus saving much time to focus on other projects and issues.
It saves us in costs, as there are no licensing requirements.
It gives us the ability to manage all of our java applets in one place, so as to be able to host both development and production systems on one server.
The platform has been stable for us so we do not experience falls or service interruptions. The investment is lower compared to other solutions in the market and we have solid support from Oracle.
