tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: Question about resetting datasources and changes to the BasicDataSource.close() method
Date Thu, 31 May 2012 19:24:45 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Brooke,

On 5/31/12 11:51 AM, Hedrick, Brooke - 43 wrote:
> Our release cycle has us releasing many applications on many JVMs 
> every week.  From time to time, these applications have issues in 
> them where someone has made a code change that requires 2
> connections per request instead of 1.  In those cases, we
> temporarily increase the MaxActive to accommodate the issue
> introduced.  We do this by using JMX as well as updating the
> server.xml ( in case the JVM is restarted for some reason ).  In
> some cases an application is released that shares a datasource with
> another application and the MaxActive isn't large enough to
> accommodate both apps.  By using JMX, we are able to increase
> MaxActive without having to take the JVM down to resolve this.
> 
> We also have cases where applications are released with connection 
> pool leaks.  When this happens, we catch problems because we keep
> the pools only big enough to service demand.  We will see
> connection pools hit 100% usage and thread pools increase rapidly
> due to waiting on connections.  We do this to prevent the database
> from being hit overly hard by a single application.  We also do not
> use the removeAbandoned settings today in favor of failing fast.
> This way the App Server suffers not the DB.  Our Tomcat hosts and
> JVMs greatly outnumber our DB hosts.

Gotcha.

> What do you do today to reset or resize connection pools?

We simply use maxActive with log/removeAbandoned. Fortunately, we have
a very well-behaved application that neither leaks connections nor
requires two connections at once, so we don't have any deadlocks. We
run with maxActive=20 and that services our current load requirements
with no problems (and no 'abandoned' notifications occur unless some
query takes a very long time to execute -- which does happen every few
months).

We never have to recycle our entire pool for any reason.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/HxX0ACgkQ9CaO5/Lv0PCY+wCdF0++ISNqpl6e2gx4Jp8xXAoI
l5QAn1RvRkYlpbXstny7EaChtZI0yqT0
=CCxl
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message