- 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)
Welcome to TomcatExpert
Home
You Can Help Improve Tomcat Adoption in the Enterprise!
How? Share your insights, use cases, comments and questions on best practices for deploying, managing and operating Apache Tomcat in the Enterprise.
Blog : Creating Custom Tools for Monitoring Tomcat, Tomcat Admin
posted by MSacks on May 17, 2010 03:07 PM
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.
Why Create Your Own Custom Tools
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.
Download tc Server
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 DownloadBlog : Deploying Tomcat Applications With Puppet
posted by mpdehaan on April 29, 2010 11:34 AM
I've heard on many occasions that Java applications are deployed 'differently' than other applications, that they are difficult, and they need Java specific management tools. Ultimately when you're managing a datacenter, you need to be able to manage applications regardless of the source language. Using administration tools that only manage one type of application or code base means an admin needs a sledgehammer in his arsenal, as well as a ball peen hammer. One tool should be sufficient and can make everyone's life easier.
The ultimate open source sledgehammer (chainsaw?) in today's datacenter automation world is Puppet. Built to be cross-platform, it works on most Linux and Unix based operating systems (including OS X), and will be taking on Windows support in the near future. It is a model driven solution that requires no coding knowledge to use. The Java community has long known the power of cross-platform tools, and systems administration tools should work the same way. If I want to create a user, do I need to know the differences between user creation on OS X and Linux? Not really, I'd just like to specify the attributes and share the same deployment instructions. Puppet helps you do this.
Puppet allows for centralized management of distributed datacenters, with many options present to account for variance in configurations and roles (queue buzzwords like "heterogenous", "geographic affinity", "cloud", and "facebook"). It allows for the definition of classes of machines ("foo.example.org" is a "database-server"), and mapping what machines belong in what classes. There are mechanisms for assigning variables and using them as conditionals and as templates. There is also a pluggable framework for customizing Puppet to interact with new systems of all kinds (such as LVM). Most importantly, Puppet is written around the concept of "modules", which are units of work that are easily shareable between developers and administrators—both inside an organization and across the internet. It is for this reason that Puppet has spawned one of the richest communities of any open source management framework—it allows admins to work together and share knowledge between workplaces, rather than inventing their own deployment tools when they take up residence in a new place. It also allows for concentrating on strategic business projects because the infrastructure automation code is already written.
Blog : Blended Source Software
posted by avanabs on April 28, 2010 11:23 AM
I've recently been working my way through a number of whitepapers from IBM and Oracle...a seemingly endless task. These guys must have more prople writing whitepapers than building the products.
In any case, one of these whitepapers, a 2009 Oracle WhitePaper discussing the DOD's large scale use of Open Source, was really interesting for two reasons. First, Tomcat is without a doubt the major factor for Open Source utilization at the enterprise level. Secondly, Oracle uses the term "Blended Source" in this whitepaper to describe today's combination of Open Source and commercial products.
Nostalgic (and Whistful) Note...feel free to skip: A few years back, in the "BO" (before Oracle) days and while BEA was still a major force in the JEE Application Server market, some of us at BEA developed a product initiative sponsored by Peter Cooper Ellis, BEA VP Engineering...one of BEA's more visionary, and successful, executives. The BEA concept was dubbed "Blended Source" by Marge Breya, CMO. I was Product Manager for the initiative and Eric Hsiao led the development team, including some of BEA's best WLS engineers.
"Blended Source" resulted from finding out how BEA's best and largest customers were really using our products. It was really simple...most of our customers were already combining the best of Open Source (Spring, Tomcat, Hyperic, etc) with BEA's Tuxedo and WLS server products to create a "blend". The opportunity we found was that each and every customer was investing in custom tooling and management to piece together these technologies. Customers were enthusiastic about BEA taking over that responsibility and ready/willing to pay for support subscriptions.
Blog : Tomcat Support: Part Four-Tomcat Self Support and Tomcat Vendors Support
posted by avanabs on April 21, 2010 09:09 AM
We've been discussing the various support options, including community support, available for Apache Tomcat, and contrasting those to Commercial JEE Application Server Support options. In this final blog in the series, we're focusing on the remaining two Tomcat Options, Self Support and Vendor Support agreements.
Tomcat Self Support
The second option is supporting Tomcat within the IT organization. In this case, the IT organization must have significant Tomcat expertise on staff and they provide much/all of the support to the various users within the organization. Both the level of expertise required and the challenges of providing that for 24x7x365 mission critical applications are neither simple nor inexpensive.
Less understood is that server infrastructure software is inherently different from application software. It’s a specialty within the software industry; relatively few programmers have the skills and expertise to deal with the kinds of problems found within operating systems and application containers. Realistically, it takes a substantial scale of operations to make this option viable, but for very large organizations, the cost savings and ability to control the process may make self support worthwhile.
Blog : Building extensions to jdbc-pool
posted by fhanik on April 19, 2010 06:08 AM
In our previous blog posts, we gave a short introduction to a new module, jdbc-pool, currently being development inside of Apache Tomcat's subversion development branch as a high concurrency alternative to connection pooling. We also covered jdbc-pool performance and how to cconfigure jdbc-pool for optimal performance.
In this article we'll dig a bit deeper under the covers and take a look at how to build extensions to the jdbc-pool. To do this, we will build a prepared statement cache for the jdbc-pool using the interceptors as a base.
A note of caution
Personally, I don't believe that connection pools should perform any level of statement caching. Here are a few reasons why:
- Statements represent resources on the database back end. Hence this cache leads to increased resources usage.
- Statement caches belong on the database, in worst case in the JDBC driver. But not in a connection pool.
- The overhead of preparing a statement can be cached and optimized on the database, rather than at a much higher level, since the overhead mainly is related to the parsing of the query.
- Statements have to be cached on a per connection basis, not making it an optimal cache for a connection pool
-
There is an API to allow the underlying driver/database to handle it using the setPoolable call.
If you take a look at a number of databases, these databases already have facilities for caching and optimizing statements, take DB2 dynamic statements as a simple example.
Setting up the interceptor
Most of the extensions in jdbc-pool can be accomplished using the JDBC interceptor base class. The interceptors all extend the invocation handler interface.
This means, that any method invocations on the Connection interface will pass through the
Object invoke(Object proxy, Method method, Object[] args) throws Throwable;
method. So if the user is calling javax.sql.PooledConnection.getConnection method we could implement that as:
1: public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
2: if (method.getDeclaringClass().equals(PooledConnection.class) &&
3: compare(GETCONNECTION_VAL,method) {
4: return connection.getConnection();
5: } else {
6: return super.invoke(proxy,method,args);
7: }
8: }- Line 2 - We check that the interface that is being called is the javax.sql.PooledConnection.getConnection class
- Line 3 - We check that the method being called is getConnection
- Line 4 - We return the underlying connection
- Line 6 - If the above conditions have not been met, pass on the request to the next interceptor.
New Content
Tomcat 7 Download Central
Happening Now on TomcatExpert
- nasobeme commented Rotating catalina.out log files
Active Members
Tags in Tags
apache
cloud computing
clustering
connection pool
deployment
enterprise
ERS
java
JEE
management
migration
Support
threads
Tomcat
Tomcat 5.5
Tomcat 6
Tomcat 7
Tomcat Admin
Tomcat Configuration
Tomcat JMX
Tomcat JVM
Tomcat Logging
Tomcat Manager
Tomcat Memory
Tomcat Performance
Tomcat Security
Tomcat SSL
Tomcat Support
Tomcat Windows
upgrade
Popular Links