Tim Holloway wrote:Unless you are planning to share that connection pool between multiple webapps, you would define it in the context.xml file, not the server.xml file.
And actually, I'm kind of confused here, since it looks like you have 2 pool definitions, one with a long JNDI resource pathname and one with a more conventional one.
Plus I didn't actually see a logAbandoned setting in the server.xml defined pool, although maybe it wrapped out of sight.
You will not see any extra logs telling you about having abandoned connections logged. Instead what happens is that when your application pulls a Connection from the monitored pool, an Exception object is created, marking the callback stack at the moment the connection was obtained. This Exception is then saved in a secret hiding place.
Periodically, the pool will check its checked-out Connections to see if they have been held longer than the allowable time. If so, then that saved Exception will be reported in the Tomcat stdout (catalina,out) log. The effect would be something like this:
Actual connection pool error-handling code and message text will vary, but the net effect is like that.
Matthew Keller wrote:Look at your application and make sure you are properly closing all open connections in a finally statement. Also, generally a database pool in tomcat has a maximum number of connections specified. Your application should borrow a connection from the tomcat pool and then return it. If you are piling up database pool connections like it sounds your are, then there is something wrong with how your application is written and freeing up resources.
Tim Holloway wrote:Try turning on the "orphan" connection detection option in your JDBC connection pool definition for Tomcat. That will cause a stack checkpoint to be taken when a Connection is checked out of the pool. If that Connection isn't closed (returned to the pool) within a reasonable amount of time, the saved stacktrace will be dumped out to the Tomcat log so that you can look for reasons why the Connection didn't close - and thus neither did the cursor.
That's assuming that Connection.close() for a pool Connection closes Statements, ResultSets and similar things attached to it - which I hadn't really considered before - except that putting a Connection back in a pool with active bits hanging off it would be trouble in its own right.
Generally, orphan connections come from sloppy programming (it only takes one mistake if you run enough connections long enough!), having an Exception thrown past the close() statement ("finally" is your friend!) or improper practices like trying to pass a Connection from one Http service request to the next (Connections are NOT Serializable/session-safe!).
Tim Holloway wrote:It's still a timeout message. Which means that either the URL is wrong, there's a firewall problem, or the remote server is down.
Tim Holloway wrote:The error message says it timed out looking for URL 'https://"URL".com/input/v1?wsdl'
That's not a valid URL. You need to put in the same servername that you used with IE.
Rob Spoor wrote:
Quincy Schmidt wrote:From the log file:
That means that something is already running on the same port (8443). Did you shutdown any previous instance of Tomcat?
To find out what's running on that port you can run netstat -ban as Administator (on Linux it's netstat -plan), then search for the port.