- Core:
- Full documentation:
- Deployer:
-
Extras:
- JMX Remote jar (pgp, md5)
- Web services jar (pgp, md5)
- JULI adapters jar (pgp, md5)
- JULI log4j jar (pgp, md5)
How? Share your insights, use cases, comments and questions on best practices for deploying, managing and operating Apache Tomcat in the Enterprise.
You've spent a lot of time setting up a private cloud of servers. Everything's virtualized and you have it organized by function. Your messaging VMs run on these hosts and your web servers run on those hosts. You've tested it extensively and you're happy with how everything talks to each other. The worst is over, right? Wrong. Now you have to move past the theoretical and actually use this thing in production. It's time to start deploying the applications you're building into this cloud of virtualized resources. It's time to develop some scheme to keep your applications updated when changes are made. Keep in mind, whatever mistakes you inject at this point will be multiplied by the number of machines that deploys to.
Scared yet?
Don't be! It's really not that hard. In this article, I'll introduce you to some concepts I used in developing the fairly simple system of messages and scripts that deploy artifacts into our private cloud. This won't be a technical HOWTO so much as it will be a casual dinner conversation about the pitfalls and rewards. Above all, I want to get across that having a bunch of virtual machines that do the same thing doesn't have to keep you up at night.
SpringSource tc Server provides enterprise users with the lightweight java app server they want along with the streamlined configuration, advanced performance monitoring, and professional support businesses need. Built as a drop-in replacement for Apache Tomcat, tc Server will instantly upgrade your custom-built and commercial software applications to Enterprise Tomcat.
Download your free trial, and try it today! Learn More »
Demo DownloadGrails is a rapid application development framework for web applications on the Java platform. It's similar in many respects to Ruby on Rails, but it's based on Java libraries, like Spring and Hibernate, and the Groovy language. It also produces standard WAR files that can be deployed to a servlet container like Tomcat. That means you can deploy Grails applications to a Tomcat cluster and in this article I'll show you how.
In order to demonstrate clustering, we need an application to deploy. Assuming that Grails is installed (I was using Grails 1.3.3 - the latest) we can create a brand new application with the command
grails create-app my-cluster-app
This will create a my-cluster-app directory containing the project. If we then switch to that directory, we can generate a WAR file straight away by running
grails war
Of course, the application doesn't do anything yet. Nor is it ready for clustering.
It used to be common practice to "spare" the Tomcat server the drudgery of serving static content like images, CSS stylesheets, and JavaScript because it was faster to do that with Apache. That really hasn't been the case for quite a while now. With Tomcat adopting NIO and some of the really low-level performance improvements of sendfile and Asynchronous IO (AIO), it's not strictly necessary to have Apache in front of Tomcat any more.
We're probably like a lot of folks, though, and we have to have an Apache server somewhere to support the PHP applications we have (bad idea, long story). Since we already have an Apache server, we also use it to serve our static resources, just like everyone's been doing for years. We started with mod_jk because that was the only viable option at the time. When mod_proxy got AJP support, we switched to using Apache's mod_proxy and saw a nice performance boost. We stayed with this configuration for several years just because it's not terribly complicated and it just works.
But fronting Tomcat servers with Apache is pretty limiting when you start talking private cloud architectures. I discovered some big problems when I first fired up our SpringSource tcServer instances fronted by a couple of DNS round-robin load-balanced Apache servers. Tomcat was getting confused because requests were coming through different front-end proxies. I wrote my own session manager, which I discussed recently in two blog posts (Part I & Part II), to get around this problem. But I still had the limitation of forcing users to go to an Apache server before being able to access the dynamic resources located in my tcServer backends. This created issues when I needed to take down the server Apache was running on.
I’ve been sharing some thoughts about what’s become a significant trend in many IT organizations, and in particular with my clients…converting Java applications from JEE Application Servers to Tomcat, and more typically Tomcat+add-ons.
Many IT organizations are re-thinking their commitment to commercial JEE Application Servers, due to both challenging business environments that drive the need for more cost effective application architectures and the need to transition to more responsive/agile applications development. When IT organizations talk about “migrating” their applications, I’ve noted that they generally are focusing on one or more of three distinct situations. These are:
I’ve been focusing on the migration of existing JEE applications to the most popular of the light weight containers, Tomcat. There are many excellent reasons to consider moving applications off of the commercial JEE servers sold by Oracle/BEA, IBM, etc. While we are focusing on the migration process, many of the business and technical decision factors apply equally well to the second and third situations.
This time, I will be discussing the technologies involved in migrating JEE application code from commercial JEE servers to Tomcat. I’d like to thank the kind (and very expert) folks at SpringSource, as well as a number of other friends around the industry, for their valuable insight regarding the technologies involved. Any errors (and opinions) are mine alone. Additionally, some of the material draws on information published by SpringSource and other open source materials found on the internet.
In my first article on taking advantage of RabbitMQ's asynchronous messaging to implement a cloud-friendly session manager, I covered the method behind the madness and introduced you to some of the functions a session manager has to perform in the course of doing its job. In this, the second of two articles covering this topic, I'll describe how loading and updating session objects is handled and, in the interest of fairness, give some disclaimers and acknowledge the trade-offs made to get here.
Whenever code wants to interact with a user session, whether that be to load it into its own memory or to replicate attributes on that session, it sends these messages to a queue whose name contains the session ID. The pattern used to create the queue name is configurable so you can partition user sessions by application, or even by something more fine-grained (without resorting to using multiple, non-clustered RabbitMQ servers).
The session store first checks its internal Map to see if the requested session happens to be local to this store. If it is, the store simply hands that session back to the manager. If it's not, then the store sends a "load" message to the session's queue. It doesn't just fire off a message, though. It turns out that a user's session can be requested from the store many times during the course of a request. If one were to send a load message every time this happens, then we would see a serious performance degradation. To get around this, before a load message is sent, the store checks to see if it's already trying to load this session. If it is, it simply waits until that process is finished and uses the session being loaded in that other thread.
Popular Links