Thanks again for all of the info.
Jerry
On 7/29/2015 1:15 PM, Christopher Schultz wrote:
Jerry,
On 7/29/15 12:06 PM, Jerry Malcolm wrote:
On 7/29/2015 10:11 AM, Christopher Schultz wrote:
I guess I could move up to the latest 8. But it'll require some
client down time, and they aren't thrilled with that at this
point.
Understood, though trying various <Resource> configurations is
certainly resulting in downtime, no?
Off topic, but relevant.... it sure would be nice if the xml
parser for <resource> tags and other config items would flag
with errors any parameter misspellings such as using the old
obsolete 'removeAbandoned' instead of the new
'removeAbandonedOnBorrow', etc. or even just typo misspells.
It does:
Jul 02, 2015 10:17:25 AM
org.apache.tomcat.dbcp.dbcp2.BasicDataSourceFactory get
ObjectInstance WARNING: Name = diagnosis Property maxActive is
not used in DBCP2, use maxTotal instead. maxTotal default value
is 8. You have set value of "1" for "maxActive" property, which
is being ignored.
...
WARNING: Name = diagnosis Property removeAbandoned is not used
in DBCP2, use one or both of removeAbandonedOnBorrow or
removeAbandonedOnMaintenance instead. Both have default value set
to false. You have set value of "true" for "removeAbandoned"
property, which is being ignored.
(I have a context.xml that I want to use between both Tomcat 7
and Tomcat 8, so I actually have both spellings of those
attributes in my XML.)
This is really strange. Are the above log entries in stdout?
Yes, so they typically end up in catalina.out. Those logs are from my
dev system's catalina.out from a recent restart.
I had 'removeAbandoned' in my resource statements until yesterday.
But I am not seeing anything in stdout like the statement above.
And after changing removeAbandoned to the correct spelling, I'm
also not seeing any abandoned log entries either.
Hmm.
Is there some sort of 'log level' that may be throttling back my
log entries? If my code has leaks, and I'm running out of
connections but not seeing any abandoned entries in the log, that
should be a concern, right?
Possibly.
Perhaps you are deploying your application more times than you
thought, and are making many more connections than you expected.
What does your <Resource> element actually look like? (Remember
to remove sensitive information such as passwords.)
<Resource name="jdbc/wgbe" testOnBorrow="true"
validationQuery="SELECT 1"
validationQuery might not be necessary anymore. I think DBCP2 does a
lightweight connection test instead issuing an actual query, unless
you override it with a validationQuery.
Also, for Connector/J, you can use "/* ping */SELECT 1" and the driver
itself will perform the lightweight connection test instead of
actually issuing a query. Much faster than going through the SQL
parser, etc.
auth="Container" type="javax.sql.DataSource" maxTotal="300"
That's a LOT of connections IMO. What is your total connection limit?
Is it per-user?
maxIdle="30" maxWaitMillis="10000" removeAbandonedOnBorrow="true"
removeAbandonedOnMaintenance="true" removeAbandonedTimeout="30"
logAbandoned="true" username="xxxxxxx" password="xxxxxxxxx"
driverClassName="org.gjt.mm.mysql.Driver"
url="jdbc:mysql://localhost:3306/wgbe?autoReconnect=true" />
Do you have the 'manager' web application installed? Can you check to
see what applications are actually deployed? If you have 2 copies
deployed, you might see 600 connections open.
Also, do you have any stray context.xml files hanging around in
conf/*/* that you weren't expecting? If you are making changes to your
configuration and they don't appear to be having any effect, it's
possible that your new configuration isn't being applied because
another config is masking it.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.6081 / Virus Database: 4392/10332 - Release Date:
07/29/15
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
