On 7/29/2015 10:11 AM, Christopher Schultz wrote:
Any reason not to upgrade to 8.0.24? 8.0.15 is nearly a year out of
date and there have been a bunch of performance, security, and
stability fixes made. It shouldn't have any effect on your current
problem, but upgrading would be worth your time.
Quick history... we migrated to a new box in January. I installed the
latest TC8 at the time. I did not read the migration notes closely, and
didn't change any of the parameter names. As expected things went
downhill pretty quickly. I quickly installed TC 7 and moved back to it
to keep the boss happy until I figured out why 8 was crashing. I found
the info about parameter changes. But by then, client was fine with
TC7, so I just let it slide until last week when I uploaded some new
code and hit that EL issue with ${...} that I discussed in another
thread. So, a good time to move back to 8 which fixed the ${...}
problem. But now I'm back to connection problems.... So, I'm on 8.0.15
simply because it was already installed. 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.
We've been on 7 for a year or two and have not had any major
issues. I read through the 7-->8 migration instructions. As
far as I can tell, I have renamed all of the resource config
parameters that changed (maxTotal, maxWaitMillis,
removedAbandonedOnBorrow).
There are two pool implementations in Tomcat 7 as well as in
Tomcat 8. Which one are you using? (Your factory = ?)
I looked at my <resource> tags, and I'm not specifying a factory
attribute at all.
Then you are using the default commons-DBCP-based connection pool. The
configuration is different for each one, so it's important we know
which one you have.
What has the default been in TC7 and TC8 without a factory being
specified?
commons-DBCP for both, though TC7 used DBCP 1.2 and TC 8 uses DBCP 2.
It's possible you have found a bug in DBCP2 but at this point, it's
unlikely since nobody else is really having this kind of problem.
Could leaving this off actually be the cause of running out of
connections?
No, it just chooses the connection pool factory.
But after running for a couple of hours, I start getting "Too
Many Connections" exceptions when connecting to the db.
Granted, there's a chance I have some connection leaks in the
code, and I'll look into those. But this hasn't been an issue
on 7 for the past year or two. And shouldn't removeAbandoned
clean those up? I've got logAbandoned set to 'true', and
nothing is showing up in the logs. Is this exception referring
to running out of available connections in the pool?
Describe "this exception" in more detail.
What component logs that message? (class, method name that
accompany the log message) Stack trace?
Stack trace at the very bottom of this note
Is there something else I need to change in the configuration
to move to Tomcat 8 that I've overlooked?
Read official documentation for Apache Commons DBCP pool
http://commons.apache.org/proper/commons-dbcp/configuration.html
Maybe you will notice some discrepancies with your
configuration.
I'll keep looking. But I'm very curious that even though I might
have connection leaks, what is preventing Tomcat from abandoning
them and returning them to the pool as I believe I have it
configured to do?
Do you have a test environment you can instrument? I highly recommend
setting maxTotal="1" (or maxActive="1" for DBCP 1.2 for Tomcat 7) and
using whatever spelling of logAbandoned="true" for your DBCP version.
That will find leaks pretty quickly, especially the ones that can
cause deadlocks in production if you aren't careful.
http://blog.christopherschultz.net/index.php/2009/03/16/properly-handlin
g-pooled-jdbc-connections/
I definitely want to find/address any leaks. But the fact that I had no
problems in TC7 and do have problems in TC8 leads me to believe I still
have some sort of configuration problem in TC8. I would like to
find/fix all config problems first before I start digging into the code
to locate/correct connection leak problems.
I've got logAbandoned set to true. But I'm not seeing a single
entry in the logs about connections being abandoned.
What's the abandoned timeout?
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? 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. 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?
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"
auth="Container"
type="javax.sql.DataSource"
maxTotal="300"
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" />
- -chris
-
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
