tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Red <redhoo...@gmail.com>
Subject Re: Connection leak Tomcat7 and Oracle
Date Fri, 06 Mar 2015 17:39:25 GMT
On 02/27/2015 11:59 AM, Christopher Schultz wrote:
> 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 <markt@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

Thank you Chris, Jeffrey, Антон, Mark and other who responded;
Chris answer really solves it for me, though I had to do some reading
and basic testing before answering. 
Thank you all again,
Red



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


Mime
View raw message