You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Jeffrey Janner <Je...@PolyDyne.com> on 2015/03/04 19:05:22 UTC

RE: Connection leak Tomcat7 and Oracle

Red -
Chris is describing exactly the way I configure my several dozen implementations, and I do not see the problems you are seeing.
I do not use global resources for exactly the reason he points out as well, I don't want to restart an entire Tomcat service just to update one app.
Also be sure to set the following parameters in your <Host> tags:
autoDeploy="false" deployXML = "false"
It is really no harder to update several files than one.  And it insures the applications only have access to the connection pools they need, not all of them.
Jeff

p.s. Top posting to make my point more noticeable by OP.

> -----Original Message-----
> From: Christopher Schultz [mailto:chris@christopherschultz.net]
> Sent: Friday, February 27, 2015 11:00 AM
> To: Tomcat Users List
> Subject: Re: Connection leak Tomcat7 and Oracle
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> Red,
> 
> On 2/27/15 11:04 AM, Red wrote:
> > On 02/27/2015 06:58 AM, Антон Мацюк wrote:
> >> 2015-02-27 1:36 GMT+02:00 Mark Thomas <ma...@apache.org>:
> >>> On 26/02/2015 22:56, Christopher Schultz wrote:
> >>>
> >>>> The solution is to put your <Resource> into your
> >>>> application's
> >>> s/The solution/The best solution/
> >>>
> >>>> context.xml and not into the site-wide defaults. Konstantin
> >>>> may not have spelled-out the solution, but he did give you
> >>>> all the information you needed to come to that conclusion on
> >>>> your own.
> >>> Another (not so good because your application is no longer
> >>> self-contained) option is to define a global resource and put
> >>> a ResourceLink into the global context.xml or the application's
> >>> context.xml.
> >>
> >> About "not so good because your application is no longer
> >> self-contained" - this is normal in case when tomcat is an
> >> sysadmin headache, and admin is bearing responsibility for both
> >> tomcat and pool in it works well. As a programmer - my job is to
> >> connect to provided datasource, and use it normally. So best
> >> approach in this situation will be use of GlobalNamingResources
> >> http://tomcat.apache.org/tomcat-7.0-
> doc/config/globalresources.html#Environment_Entries
> >>
> >>
> to store there my jdbc-pools and just make ResourceLink
> >> http://tomcat.apache.org/tomcat-7.0-
> doc/config/globalresources.html#Resource_Links
> >>
> >>
> in application's META_INF/context.xml to get this datasource from
> >> global context.
> >>
> >> ---------------------------------------------------------------------
> >>
> >>
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: users-help@tomcat.apache.org
> >>
> > Thank You all; I have come to same conclusions, though they vastly
> > differ from what I have expected. I have found spare Oracle Linux
> > 6.5 machine , downloaded latest tomcat 8.0.20, java is 1.7.0_65.
> > Behaviour is the same, tomcat opens 50 conenctions to database.
> > After moving pool definition from conf/context.xml to
> > webapps/manager/META-INF/context.xml, tomcat opens 10 connections.
> > Reading, then, this is default value of pool initial size (tenth of
> > maxActive, default 100).
> 
> You have maxActive="10". The default value of initialSize is supposed
> to be "0". I'm surprised it's opening 10 connections immediately.
> 
> > After explicitly defining initialSize="1", only single connection
> > is opened.  Good. Now moving that pool definition back to
> > conf/context.xml, I get five connections to db.  There is total 5
> > apps deployed by default (ROOT. manager, hostmanager, docs and
> > examples).  Basically, each app opens every connection pool defined
> > in conf/context.xml to the tune of initialSize.
> 
> Correct. This is exactly what you have asked Tomcat to do: define a
> default DataSource for all web applications. Note that it's *not a
> shared data source between all the web applications*. Instead, it's a
> DataSource that will be created for *each web application you deploy*.
> 
> So, if the DataSource opens up 10 connections and you have 10 web
> applications, you'll get 100 connections to the database.
> 
> (I'm not exactly sure why they are being opened immediately, but you
> are in fact getting 10 DataSources.)
> 
> > At my place we have about 25 applications in each dev and prod,
> > with about 10-15 database pools defined.  Even with initialSize set
> > to 1, that comes to total over 300 connections, which makes
> > conf/context.xml useless for me.  If so, connections pools must be
> > moved to application context.xml.
> 
> You should be doing this anyway. It's very rare for a whole server
> full of applications to need the same DataSource configuration(s).
> 
> > Well, this is maintenance nightmare for me, as passwords are
> > changed regularly, and I have to edit every single app context.xml
> > file.
> 
> Learn to script things.
> 
> > On top of it, we deploy .war files, and context.xml are part of
> > it.
> 
> If you use a separate deployment descriptor in
> conf/[engine]/[hostname]/[appname].xml, then the deployment descriptor
> in the WAR file will be ignored.
> 
> > In dev, I do not care, but for production, .war has to be packed
> > with context.xml in it (with conn info).
> 
> Does it?
> 
> > As a dba, I refuse to give prod passwords to developers
> 
> Then don't.
> 
> > So I will have to package/repackage not only on initial
> > deployment, but on every app update.
> 
> Untrue. See above.
> 
> > Please tell me that I am wrong
> 
> You are wrong.
> 
> > because as it look now whole purpose of connection pooling is
> > defeated, and that can not be.   Hostmanager (for example) does not
> > have any oracle connection defined within itself, so why it should
> > even know those exist, not to mention to actually open them.
> 
> Agreed. Stop defining DataSources in conf/context.xml.
> 
> When you deploy an application, your application's
> META-INF/context.xml and conf/context.xml are merged and treated as
> "/the/ configuration" for the application. So stop defining default
> application configuration if you don't want it to be the default
> application configuration.
> 
> > I will do reading on this, suggested above first, but my objective
> > is clear.  Single file with all pools, apps ask for and use/open
> > only pools needed.  I believe that is how it was in tomcat6.
> 
> If you want a single file with all pools, you'll need to configure a
> global resource in server.xml and then map them into each web
> application using <ResourceLink>(s). Note that changing the DataSource
> configuration will require you to restart the *whole container*
> instead of just the application if you want to change it.
> 
> > If anyone knows how to achieve this please let me know (I did not
> > have chance yet to go though links provided since yesterday, so my
> > answer might be there).
> 
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: GPGTools - http://gpgtools.org
> 
> iQIcBAEBCAAGBQJU8KJ/AAoJEBzwKT+lPKRYysYQAI67V5qOHk7aiF570bU/qG/c
> uU5IiyuAjMfFRIwtEzX7/gfe+b5G9yUZXZ5I54x2YUC4cgLFRX8wL/6dZbPimsER
> UAieqz+SrHcrxNDWaweWlbm6Y0TxW1NZ7+Ej4GujchxGmqDJpKBvehPcQ2OTw19C
> g+Y/7OL/7iAP5WJCT4lY/IEWRgbLzTDwiIEAGFDnzfYo22Yf2Ks37lTcSmSHalMV
> m2wZX0aCbg+8/Yq9PjqG/awai24LirqpB2YN3kuRhDyA1yYhQnQwGvdTEKw2Pc+B
> 3xy4mgH39BqpzCmUhf2nxn8cxa4sQuJkLqjCexF8LcT0KFrjk8Iwn9m56dHOHLzh
> DjNFuQ2yX0HdvgFpFylJG9DWDaWEbkKzD1W4EQNESmfEWiVUwBd4nBW/8QXfmszR
> ShE7sLuckihMK308sKM8G8ny3zADggnp1Ai+2aqtqj6HnYHL+/QamxithINtjkWD
> RT2xfzp7rW9n+/zxV9N4PXIR5COnrqKay+aZEL2xrnn+U6s4Uat3kh+z4axRd4zs
> FfoeM5/GvGwDfSTduiE35Ety8J3pWoonwF+hJeNwByspVfqP2cJT8TU4purWkmwH
> n5DrcxX0kxRTOS7qvtVlYUQoq7EbFn6Zzgs2HSpM7/TcOad5ACyj0XgKrDYHoHPt
> lGUi3AwSzNBmvI23MeF8
> =wB1Q
> -----END PGP SIGNATURE-----
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org