Tomcat itself listens on the channels defined by its Connection elements defined in the TOMCAT_HOME/conf/server.xml file. The Connectors affilitate with a pool so that Tomcat can handle multiple connections at a time efficiency. A connector is pulled from this pool are to receive an incoming client request and to provide the reply channel for the Response. HTTP is not a continuous-connection protocol, so the connection lasts only from the time of the request coming in to the end of the response going out. At that time, the network connection to/from the client is closed by Tomcat until/if the client makes another request. More in a moment.
A
JDBC Database Connection done using a Tomcat Connection Pool is somewhat similar except that it maintains a collection of open network connections to the database, and supplies them to the application on demand. The web application uses the database Connection, then MUST close it to return it to the Connection Pool for re-use. And note that in any event, a Connection MUST NOT be saved between HTTP (
servlet) requests! It must always be closed before the Response is complete.
OK. Now for the limits and constraints. As is the case for all standard ICP/IP applications, Tomcat has a central connection point attached to its incoming ports. This is where the connection request is bound to a connection handler. The handler attempts to obtain a request processor Thread from its request pool. If it cannot obtain one, the request is held until a Thread becomes available. If the request queue itself fills up, then the connection point stops accepting requests and they simply bounce (the client will probably display a "server busy" or "unable to connect" message). So that should not be inherently fatal.
Similarly, when a JDBC Connection Pool runs out of Connections, the Pool first looks to see if it's allowed to make more Connections. If it can't, then the request by the application for a Connection will fail. The application should be coded to allow for that and display a "Database busy" page or something to the user.
Again, this should not crash Tomcat.
What CAN cause problems is when a mis-coded application doesn't manage resources effectively. If a servlet/JSP request takes to long to process, it interferes with Tomcat's ability to pass out processing threads. Likewise, if an application holds a JDBC Connection too long, it interferes with effective operation of the JDBC Connection Pool.
The #1 rule then, is that a Servlet or
JSP should spend as little time as possible getting from the request to the end of the Response. HTTP does NOT like it when you expect a servlet to run a request for 30 minutes. Or even 5. In fact, 1 minute is pushing it. If you need a long-running process to execute from a web request there are tricks to that, but a servlet shouldn't attempt to run such processes directly.
Now let's say that the apps are all well-behaved. Well, you can still have issues if, say, 40,000 users all descend on the server at once because they're all making legitimate requests there. At that point, you may need to tweak the Connector and/or Connection Pool settings to handle the load. And possibly consider an elastic solution with multiple Tomcat instances to spread the load around.
Finally, there's one last limit to consider. The OS itself has only a finite number of connections available for ALL apps (Java and otherwise) on the system. Some systems, such as the Oracle DBMS server will adjust the default limit, since they know that they're going to want more. However there is a fixed numerical limit.
Now, as far as your particular error, it's a little hard to tell. I think that the "Ready" connections are connections maintained by HTTP keep-alive to make it faster for repeat connections from clients, but I could be wrong. The most fearsome message is Out Of Memory. That means that you don't have you JVM memory parameters set high enough to allow for the work that needs to be done. You can set the environment variable CATALINA_OPTS to override these JVM options.
Beyond that, about all I can say is that if Tomcat dies, copy the stack trace and paste it (as TEXT, please, no screenshots!) into this message thread.
