You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Red <re...@gmail.com> on 2015/02/24 22:20:00 UTC
Connection leak Tomcat7 and Oracle
OS: Ubuntu 14.04.2 LTS
Oracle: 12.1.0.1.0 or 11.2.0.3.0
Tomcat: 7.0.52-1ubuntu0.1
odjbc: Ojdbc6 or Ojdbc7 (placed in /var/lib/tomcat7/lib)
java version "1.8.0_31" of "1.7.0_65"
Context.xml:
<Resource name="*********1" auth="Container"
type="javax.sql.DataSource"
driverClassName="oracle.jdbc.OracleDriver"
url="jdbc:oracle:thin:@//*********:1521/********"
minIdle="1"
username="*******" password="*******" maxActive="10"
maxIdle="10" maxWait="-1" />
<Resource name="******2" auth="Container"
type="javax.sql.DataSource"
driverClassName="oracle.jdbc.OracleDriver"
url="jdbc:oracle:thin:@//*******:1521/**********"
username="*******" password="**********" maxActive="20"
maxIdle="10" maxWait="-1" />
Immediately after tomcat startup, number of connection goes up until it
reaches below:
SQL> select machine, username, count (1) from v$session group by
machine, username;
MACHINE USERNAME COUNT(1)
--------- --------------------- ----------
tc ******1 40
tc ******2 60
Then, after a while connection count drops to:
MACHINE USERNAME COUNT(1)
--------- --------------------- ----------
tc ******1 6
tc ******2 60
I have commented all other pools, most fail due to lack of resources on
database side (hundreeds of connections). Connection are opened if pool
is defined in context.xml, even if actually not used anywhere.
Catalina.out gives me nothing for two pools, bunch of errors with 3 or
more, but those seem to be due to exhaustion of databases availability.
Looked up oracle support, nothing of use there. All of this works fine
with tomcat6, java6, oracle 11g or 12c
Red
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Connection leak Tomcat7 and Oracle
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 24. Februar 2015 22:20:00 MEZ, schrieb Red <re...@gmail.com>:
>OS: Ubuntu 14.04.2 LTS
>Oracle: 12.1.0.1.0 or 11.2.0.3.0
>Tomcat: 7.0.52-1ubuntu0.1
>odjbc: Ojdbc6 or Ojdbc7 (placed in /var/lib/tomcat7/lib)
>java version "1.8.0_31" of "1.7.0_65"
>
>Context.xml:
> <Resource name="*********1" auth="Container"
> type="javax.sql.DataSource"
>driverClassName="oracle.jdbc.OracleDriver"
> url="jdbc:oracle:thin:@//*********:1521/********"
>minIdle="1"
> username="*******" password="*******" maxActive="10"
>maxIdle="10" maxWait="-1" />
> <Resource name="******2" auth="Container"
> type="javax.sql.DataSource"
>driverClassName="oracle.jdbc.OracleDriver"
> url="jdbc:oracle:thin:@//*******:1521/**********"
> username="*******" password="**********" maxActive="20"
>maxIdle="10" maxWait="-1" />
>
>Immediately after tomcat startup, number of connection goes up until it
>reaches below:
>
>SQL> select machine, username, count (1) from v$session group by
>machine, username;
>
>MACHINE USERNAME COUNT(1)
>--------- --------------------- ----------
>tc ******1 40
>tc ******2 60
>
>Then, after a while connection count drops to:
>
>MACHINE USERNAME COUNT(1)
>--------- --------------------- ----------
>tc ******1 6
>tc ******2 60
>
>
>
>I have commented all other pools, most fail due to lack of resources on
>database side (hundreeds of connections). Connection are opened if
>pool
>is defined in context.xml, even if actually not used anywhere.
>
>Catalina.out gives me nothing for two pools, bunch of errors with 3 or
>more, but those seem to be due to exhaustion of databases availability.
>
>Looked up oracle support, nothing of use there. All of this works fine
>with tomcat6, java6, oracle 11g or 12c
Apart from the answers you already got. Take a look at the troubleshooting guide http://wiki.apache.org/tomcat/FAQ/Troubleshooting_and_Diagnostics . Maybe the starting takes long enough to see where your connections are taken.
Another thing you can do is to configure your pools to report abandoned connections. That way you will see where the connections where created.
Felix
>
>Red
>
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Connection leak Tomcat7 and Oracle
Posted by Mark Thomas <ma...@apache.org>.
On 24/02/2015 21:20, Red wrote:
> OS: Ubuntu 14.04.2 LTS
> Oracle: 12.1.0.1.0 or 11.2.0.3.0
> Tomcat: 7.0.52-1ubuntu0.1
> odjbc: Ojdbc6 or Ojdbc7 (placed in /var/lib/tomcat7/lib)
> java version "1.8.0_31" of "1.7.0_65"
>
> Context.xml:
Which context.xml file?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Connection leak Tomcat7 and Oracle
Posted by Jeffrey Janner <Je...@PolyDyne.com>.
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
Re: Connection leak Tomcat7 and Oracle
Posted by Red <re...@gmail.com>.
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 <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
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
Re: Connection leak Tomcat7 and Oracle
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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
Re: Connection leak Tomcat7 and Oracle
Posted by Red <re...@gmail.com>.
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). 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.
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. Well, this is maintenance nightmare for me, as passwords
are changed regularly, and I have to edit every single app context.xml
file. On top of it, we deploy .war files, and context.xml are part of
it. In dev, I do not care, but for production, .war has to be packed
with context.xml in it (with conn info). As a dba, I refuse to give
prod passwords to developers, So I will have to package/repackage not
only on initial deployment, but on every app update.
Please tell me that I am 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.
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 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).
Thank you all and will let you know how it goes,
Red
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Connection leak Tomcat7 and Oracle
Posted by Антон Мацюк <de...@gmail.com>.
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
Re: Connection leak Tomcat7 and Oracle
Posted by 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.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Connection leak Tomcat7 and Oracle
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Red,
On 2/26/15 5:28 PM, Red wrote:
> On 02/26/2015 12:29 PM, Konstantin Kolinko wrote:
>> 2015-02-26 19:28 GMT+03:00 Red <re...@gmail.com>:
>>> Thank You all who responded; Did not want to waste your time,
>>> hence delayed response.
>>>
>>> To make sure no customization has been made on my end I have
>>> completely rebuilt system: Install OS (Ubuntu 14.04.2 LTS)
>>> including reformat of all drives, selected tomcat7 and ssh
>>> server during install when asked. Run apt-get update and
>>> upgrade, rebooted, checked java -version, this time shows
>>> OpenJDK Runtime Environment (IcedTea 2.4.7)
>>> (7u55-2.4.7-1ubuntu1). So far this is out of the box setup.
>> http://wiki.apache.org/tomcat/FAQ/Linux_Unix#Q5
>>
>>> Created directory /var/lib/tomcat7/lib, as this directory is
>>> referenced in catalina properties as path for common loader
>>> (common.loader=${catalina.base}/lib,${catalina.base}/lib/*.jar,....)
>>> and placed odbc7.jar into it. Now I modify
>>> /etc/tomcat7/context.xml
>> The above is the answer to the question that Mark asked you in
>> the very first response on this thread.
>>
>> You have edited the file that provides defaults. So *each*
>> deployed web application has its own copy of the connection
>> pool.
>>
>>
>>> adding following:
>>>
>>> <Resource name="*******" auth="Container"
>>> type="javax.sql.DataSource"
>>> driverClassName="oracle.jdbc.OracleDriver"
>>> factory="org.apache.tomcat.jdbc.pool.DataSourceFactory"
>>> url="jdbc:oracle:thin:@//myserver:1521/myfqservicename"
>>> username="******" password="********" maxActive="20"
>>> maxIdle="10" maxWait="-1"/>
>>>
>>> So to be clear, no application have been deployed (except what
>>> came with tomcat, ie 'ROOT"), and no user connected. No errors
>>> in catalina.out. Now, time to check database connections:
>>>
>>> SQL>select machine, username, count (1) from v$session where
>>> machine = '**' group by machine, username;
>>>
>>> MACHINE USERNAME COUNT(1) --------- -------------
>>> ---------- ** ******** 50
>>>
>>> When I stop tomcat all connections are gone. Now, above
>>> context setting (except factory=... which I just added) works
>>> fine in tomcat6, java6 environment, target database is the
>>> same.
>>>
>>> Could anyone sent me working pool definition for: Ubunutu 14,
>>> tomcat7, java7, oracle12c or 11gR2. And, most importantly, is
>>> this reproducible?
>>>
>>> Thank you all again.
>>>
>>> Red
>>>
>> Mailing list rules:
>> http://tomcat.apache.org/lists.html#tomcat-users -> 6.
>> Top-posting is bad.
>>
>> Best regards, Konstantin Kolinko
>>
>> ---------------------------------------------------------------------
>>
>>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
> Hi Konstantin; Thank you for response and apologies for top
> posting. I have done some more testing, and understand what is
> problem, though no solution. But I am sure those who know tomcat
> better will be able to answer right away if solution is there or
> not. It will take me a bit of time to explain, and now it late in
> NY, so tomorrow morning. Posting this only for other who might be
> looking do not waste time replicating issue.
The solution is to put your <Resource> into your application's
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.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQIbBAEBCAAGBQJU76S3AAoJEBzwKT+lPKRYsmkP9j6O7FBTyWwz+uiyYEcKw+bA
KoF3vvB4MCBb16ZlaDTeeZeyKkrdDTvf5gMx8zP//Nc6WgEkhyc5ZtxlHEqJSzt2
ZylHEequqP99CFygdroDn+uElnzqu8nMPVZOpkjaPhkvtDnioriKzTKql7v6iHTb
atY48LWnYMzNM45ZTCzA2z8LEb9Blezk5fe52/6imaA7AraXjNEAhkURBfbz5L6M
fV+/sby6oq9GKUFZXbzkcCwi2DikZcfeNa9ltFC9lRTEMU3GIrjFnSLq2mO+8Q5D
haPOEYvVKM98tTBjq+dDoPsygk93G3cY0cUeq53aAkpT/ED7q+pecPkjVLGvxl95
/0WgO6OelMtDYdg+trJ2br6bsqumLVQJhT68sazfy8nK3FmUIJ7dYL+UwLKWOgME
iCcTD0HO7TKfMOETuiduZVF6Ua2YCYJXzoA1LAy6naSomC1lW7GDexJlippm819c
TutTQPXFiPGjEbl9E3IV6uWMUR1ji3mDps4TqcmnGjA7cOvguMoEJNknJTWiF0xU
BP3PExuFmYls/iGV/NvBehWZGgO1HcFfrueWlrVqnLXG0pX0V3EE0Yj4hZvYpF7r
wQXftn0Ft5kwTjwSWh63M/jC04kuTLrz1W6j9ngPhTWEQfDtEPkTTWEzCLy3XmZk
gUNOsJn5uWhXPIn7/Ec=
=REsN
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Connection leak Tomcat7 and Oracle
Posted by Red <re...@gmail.com>.
On 02/26/2015 12:29 PM, Konstantin Kolinko wrote:
> 2015-02-26 19:28 GMT+03:00 Red <re...@gmail.com>:
>> Thank You all who responded;
>> Did not want to waste your time, hence delayed response.
>>
>> To make sure no customization has been made on my end I have completely
>> rebuilt system: Install OS (Ubuntu 14.04.2 LTS) including reformat of
>> all drives, selected tomcat7 and ssh server during install when asked.
>> Run apt-get update and upgrade, rebooted, checked java -version, this
>> time shows OpenJDK Runtime Environment (IcedTea 2.4.7)
>> (7u55-2.4.7-1ubuntu1). So far this is out of the box setup.
> http://wiki.apache.org/tomcat/FAQ/Linux_Unix#Q5
>
>> Created directory /var/lib/tomcat7/lib, as this directory is referenced
>> in catalina properties as path for common loader
>> (common.loader=${catalina.base}/lib,${catalina.base}/lib/*.jar,....) and
>> placed odbc7.jar into it. Now I modify /etc/tomcat7/context.xml
> The above is the answer to the question that Mark asked you in the
> very first response on this thread.
>
> You have edited the file that provides defaults. So *each* deployed
> web application has its own copy of the connection pool.
>
>
>> adding following:
>>
>> <Resource name="*******" auth="Container"
>> type="javax.sql.DataSource"
>> driverClassName="oracle.jdbc.OracleDriver"
>> factory="org.apache.tomcat.jdbc.pool.DataSourceFactory"
>> url="jdbc:oracle:thin:@//myserver:1521/myfqservicename"
>> username="******" password="********" maxActive="20"
>> maxIdle="10" maxWait="-1"/>
>>
>> So to be clear, no application have been deployed (except what came with
>> tomcat, ie 'ROOT"), and no user connected. No errors in catalina.out.
>> Now, time to check database connections:
>>
>> SQL>select machine, username, count (1) from v$session where machine =
>> '**' group by machine, username;
>>
>> MACHINE USERNAME COUNT(1)
>> --------- ------------- ----------
>> ** ******** 50
>>
>> When I stop tomcat all connections are gone. Now, above context
>> setting (except factory=... which I just added) works fine in tomcat6,
>> java6 environment, target database is the same.
>>
>> Could anyone sent me working pool definition for: Ubunutu 14, tomcat7,
>> java7, oracle12c or 11gR2. And, most importantly, is this reproducible?
>>
>> Thank you all again.
>>
>> Red
>>
> Mailing list rules:
> http://tomcat.apache.org/lists.html#tomcat-users
> -> 6. Top-posting is bad.
>
> Best regards,
> Konstantin Kolinko
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
Hi Konstantin;
Thank you for response and apologies for top posting. I have done some
more testing, and understand what is problem, though no solution. But I
am sure those who know tomcat better will be able to answer right away
if solution is there or not.
It will take me a bit of time to explain, and now it late in NY, so
tomorrow morning. Posting this only for other who might be looking do
not waste time replicating issue.
Till morning,
Red
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Connection leak Tomcat7 and Oracle
Posted by Konstantin Kolinko <kn...@gmail.com>.
2015-02-26 19:28 GMT+03:00 Red <re...@gmail.com>:
> Thank You all who responded;
> Did not want to waste your time, hence delayed response.
>
> To make sure no customization has been made on my end I have completely
> rebuilt system: Install OS (Ubuntu 14.04.2 LTS) including reformat of
> all drives, selected tomcat7 and ssh server during install when asked.
> Run apt-get update and upgrade, rebooted, checked java -version, this
> time shows OpenJDK Runtime Environment (IcedTea 2.4.7)
> (7u55-2.4.7-1ubuntu1). So far this is out of the box setup.
http://wiki.apache.org/tomcat/FAQ/Linux_Unix#Q5
> Created directory /var/lib/tomcat7/lib, as this directory is referenced
> in catalina properties as path for common loader
> (common.loader=${catalina.base}/lib,${catalina.base}/lib/*.jar,....) and
> placed odbc7.jar into it. Now I modify /etc/tomcat7/context.xml
The above is the answer to the question that Mark asked you in the
very first response on this thread.
You have edited the file that provides defaults. So *each* deployed
web application has its own copy of the connection pool.
> adding following:
>
> <Resource name="*******" auth="Container"
> type="javax.sql.DataSource"
> driverClassName="oracle.jdbc.OracleDriver"
> factory="org.apache.tomcat.jdbc.pool.DataSourceFactory"
> url="jdbc:oracle:thin:@//myserver:1521/myfqservicename"
> username="******" password="********" maxActive="20"
> maxIdle="10" maxWait="-1"/>
>
> So to be clear, no application have been deployed (except what came with
> tomcat, ie 'ROOT"), and no user connected. No errors in catalina.out.
> Now, time to check database connections:
>
> SQL>select machine, username, count (1) from v$session where machine =
> '**' group by machine, username;
>
> MACHINE USERNAME COUNT(1)
> --------- ------------- ----------
> ** ******** 50
>
> When I stop tomcat all connections are gone. Now, above context
> setting (except factory=... which I just added) works fine in tomcat6,
> java6 environment, target database is the same.
>
> Could anyone sent me working pool definition for: Ubunutu 14, tomcat7,
> java7, oracle12c or 11gR2. And, most importantly, is this reproducible?
>
> Thank you all again.
>
> Red
>
Mailing list rules:
http://tomcat.apache.org/lists.html#tomcat-users
-> 6. Top-posting is bad.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Connection leak Tomcat7 and Oracle
Posted by Red <re...@gmail.com>.
Thank You all who responded;
Did not want to waste your time, hence delayed response.
To make sure no customization has been made on my end I have completely
rebuilt system: Install OS (Ubuntu 14.04.2 LTS) including reformat of
all drives, selected tomcat7 and ssh server during install when asked.
Run apt-get update and upgrade, rebooted, checked java -version, this
time shows OpenJDK Runtime Environment (IcedTea 2.4.7)
(7u55-2.4.7-1ubuntu1). So far this is out of the box setup.
Created directory /var/lib/tomcat7/lib, as this directory is referenced
in catalina properties as path for common loader
(common.loader=${catalina.base}/lib,${catalina.base}/lib/*.jar,....) and
placed odbc7.jar into it. Now I modify /etc/tomcat7/context.xml adding
following:
<Resource name="*******" auth="Container"
type="javax.sql.DataSource"
driverClassName="oracle.jdbc.OracleDriver"
factory="org.apache.tomcat.jdbc.pool.DataSourceFactory"
url="jdbc:oracle:thin:@//myserver:1521/myfqservicename"
username="******" password="********" maxActive="20"
maxIdle="10" maxWait="-1"/>
So to be clear, no application have been deployed (except what came with
tomcat, ie 'ROOT"), and no user connected. No errors in catalina.out.
Now, time to check database connections:
SQL>select machine, username, count (1) from v$session where machine =
'**' group by machine, username;
MACHINE USERNAME COUNT(1)
--------- ------------- ----------
** ******** 50
When I stop tomcat all connections are gone. Now, above context
setting (except factory=... which I just added) works fine in tomcat6,
java6 environment, target database is the same.
Could anyone sent me working pool definition for: Ubunutu 14, tomcat7,
java7, oracle12c or 11gR2. And, most importantly, is this reproducible?
Thank you all again.
Red
On 02/24/2015 05:54 PM, Filip Hanik wrote:
> unless DBCP changed of course.
>
> I would add
> the following property to your <Resource> element
>
>
> factory="org.apache.tomcat.jdbc.pool.DataSourceFactory"
>
> http://tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html
>
>
>
> On Tue, Feb 24, 2015 at 3:47 PM, Christopher Schultz <
> chris@christopherschultz.net> wrote:
>
> Red,
>
> On 2/24/15 4:20 PM, Red wrote:
> >>> OS: Ubuntu 14.04.2 LTS Oracle: 12.1.0.1.0 or 11.2.0.3.0 Tomcat:
> >>> 7.0.52-1ubuntu0.1 odjbc: Ojdbc6 or Ojdbc7 (placed in
> >>> /var/lib/tomcat7/lib) java version "1.8.0_31" of "1.7.0_65"
> >>>
> >>> Context.xml: <Resource name="*********1" auth="Container"
> >>> type="javax.sql.DataSource"
> >>> driverClassName="oracle.jdbc.OracleDriver"
> >>> url="jdbc:oracle:thin:@//*********:1521/********" minIdle="1"
> >>> username="*******" password="*******" maxActive="10" maxIdle="10"
> >>> maxWait="-1" /> <Resource name="******2" auth="Container"
> >>> type="javax.sql.DataSource"
> >>> driverClassName="oracle.jdbc.OracleDriver"
> >>> url="jdbc:oracle:thin:@//*******:1521/**********"
> >>> username="*******" password="**********" maxActive="20"
> >>> maxIdle="10" maxWait="-1" />
> >>>
> >>> Immediately after tomcat startup, number of connection goes up
> >>> until it reaches below:
> >>>
> >>> SQL> select machine, username, count (1) from v$session group by
> >>> machine, username;
> >>>
> >>> MACHINE USERNAME COUNT(1) ---------
> >>> --------------------- ---------- tc ******1
> >>> 40 tc ******2 60
> >>>
> >>> Then, after a while connection count drops to:
> >>>
> >>> MACHINE USERNAME COUNT(1) ---------
> >>> --------------------- ---------- tc ******1 6
> >>> tc ******2 60
> >>>
> >>>
> >>>
> >>> I have commented all other pools, most fail due to lack of
> >>> resources on database side (hundreeds of connections). Connection
> >>> are opened if pool is defined in context.xml, even if actually not
> >>> used anywhere.
> >>>
> >>> Catalina.out gives me nothing for two pools, bunch of errors with 3
> >>> or more, but those seem to be due to exhaustion of databases
> >>> availability.
> >>>
> >>> Looked up oracle support, nothing of use there. All of this works
> >>> fine with tomcat6, java6, oracle 11g or 12c
>
> So which one of these makes a difference? Tomcat's connection pool
> didn't change dramatically between Tomcat 6 and 7. The Java version
> likely has nothing to do with it, and the Oracle version also likely
> has nothing to do with it.
>
> So what's the problem?
>
> Has your application's user behavior changed in any way? Say, an
> increase in traffic?
>
> What you describe sounds an awful lot like poor resource management in
> the application itself.
>
> 1. Are you sure every part of your application is using your JDBC pools?
>
> 2. Read this:
>
> http://blog.christopherschultz.net/index.php/2009/03/16/properly-handling-pooled-jdbc-connections/
>
> -chris
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
Re: Connection leak Tomcat7 and Oracle
Posted by Filip Hanik <fi...@hanik.com>.
unless DBCP changed of course.
I would add
the following property to your <Resource> element
factory="org.apache.tomcat.jdbc.pool.DataSourceFactory"
http://tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html
On Tue, Feb 24, 2015 at 3:47 PM, Christopher Schultz <
chris@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Red,
>
> On 2/24/15 4:20 PM, Red wrote:
> > OS: Ubuntu 14.04.2 LTS Oracle: 12.1.0.1.0 or 11.2.0.3.0 Tomcat:
> > 7.0.52-1ubuntu0.1 odjbc: Ojdbc6 or Ojdbc7 (placed in
> > /var/lib/tomcat7/lib) java version "1.8.0_31" of "1.7.0_65"
> >
> > Context.xml: <Resource name="*********1" auth="Container"
> > type="javax.sql.DataSource"
> > driverClassName="oracle.jdbc.OracleDriver"
> > url="jdbc:oracle:thin:@//*********:1521/********" minIdle="1"
> > username="*******" password="*******" maxActive="10" maxIdle="10"
> > maxWait="-1" /> <Resource name="******2" auth="Container"
> > type="javax.sql.DataSource"
> > driverClassName="oracle.jdbc.OracleDriver"
> > url="jdbc:oracle:thin:@//*******:1521/**********"
> > username="*******" password="**********" maxActive="20"
> > maxIdle="10" maxWait="-1" />
> >
> > Immediately after tomcat startup, number of connection goes up
> > until it reaches below:
> >
> > SQL> select machine, username, count (1) from v$session group by
> > machine, username;
> >
> > MACHINE USERNAME COUNT(1) ---------
> > --------------------- ---------- tc ******1
> > 40 tc ******2 60
> >
> > Then, after a while connection count drops to:
> >
> > MACHINE USERNAME COUNT(1) ---------
> > --------------------- ---------- tc ******1 6
> > tc ******2 60
> >
> >
> >
> > I have commented all other pools, most fail due to lack of
> > resources on database side (hundreeds of connections). Connection
> > are opened if pool is defined in context.xml, even if actually not
> > used anywhere.
> >
> > Catalina.out gives me nothing for two pools, bunch of errors with 3
> > or more, but those seem to be due to exhaustion of databases
> > availability.
> >
> > Looked up oracle support, nothing of use there. All of this works
> > fine with tomcat6, java6, oracle 11g or 12c
>
> So which one of these makes a difference? Tomcat's connection pool
> didn't change dramatically between Tomcat 6 and 7. The Java version
> likely has nothing to do with it, and the Oracle version also likely
> has nothing to do with it.
>
> So what's the problem?
>
> Has your application's user behavior changed in any way? Say, an
> increase in traffic?
>
> What you describe sounds an awful lot like poor resource management in
> the application itself.
>
> 1. Are you sure every part of your application is using your JDBC pools?
>
> 2. Read this:
>
> http://blog.christopherschultz.net/index.php/2009/03/16/properly-handling-pooled-jdbc-connections/
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBCAAGBQJU7P9wAAoJEBzwKT+lPKRYX/YP/ijgvvieYaNlgaM7cODgPPzm
> 4GdEyJfXW+xQA5HBOBQemz5CX8YWrSgr9PrlSumf/uU6mx57G1yhmDdmwv1N5jnJ
> ct9hBU97aw/6t7FiGF+JPyEjbhETBRIZB5NoOKPiP8CNJeTMd8a9z1Qe6aU1oXMM
> yPtsvzg7J5aziKzpdm9xrb0lXtdQe9ga5YfikPShS6Tup1iJzcCImi27RQ6nuUFY
> zC8wHVmz0PU8UcbLpFDQGTTUsq6JtQvR/aGpDcHYfq8dNqavnP/QECcx6ZQlixy6
> HX30Oj4s/D/I5ez8PXAo2PiSF4ZZ86j0UQt9ntqcDeE7w7ldIfLQ2NCj5jANS6SL
> coG3n0tszmVSfCQ3fCXsTphbry0NZSJjNwmkZ4ezXj+3KpD5oATbaTLVL9ZeH9s4
> d3HiheNcF//pdeGDZ5Zy09vAO94V9CD+fr2TbbovluHzgpuOu7vYqAwg6IzuMQfs
> QWwmiC+Rccp6PnWltSJ7ClIKTh9mDHI7cejdFmQJe4J0kN7HZHggkk7ZlJD5/p6h
> sEVxmBZ0JMm0GJzoqOurtHKrviqvbfOJhXd5w6Jmv9Dyj7yK/izhXkACmOp7Rz9K
> 9/T1OQsyWBtbWho8/xdisEUvsuY9w3lIf2uIeQmikIpICQ4NYddxz5I3/zpd8CSo
> KApJwDf0qsXvXduOrANP
> =F0TE
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Connection leak Tomcat7 and Oracle
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Red,
On 2/24/15 4:20 PM, Red wrote:
> OS: Ubuntu 14.04.2 LTS Oracle: 12.1.0.1.0 or 11.2.0.3.0 Tomcat:
> 7.0.52-1ubuntu0.1 odjbc: Ojdbc6 or Ojdbc7 (placed in
> /var/lib/tomcat7/lib) java version "1.8.0_31" of "1.7.0_65"
>
> Context.xml: <Resource name="*********1" auth="Container"
> type="javax.sql.DataSource"
> driverClassName="oracle.jdbc.OracleDriver"
> url="jdbc:oracle:thin:@//*********:1521/********" minIdle="1"
> username="*******" password="*******" maxActive="10" maxIdle="10"
> maxWait="-1" /> <Resource name="******2" auth="Container"
> type="javax.sql.DataSource"
> driverClassName="oracle.jdbc.OracleDriver"
> url="jdbc:oracle:thin:@//*******:1521/**********"
> username="*******" password="**********" maxActive="20"
> maxIdle="10" maxWait="-1" />
>
> Immediately after tomcat startup, number of connection goes up
> until it reaches below:
>
> SQL> select machine, username, count (1) from v$session group by
> machine, username;
>
> MACHINE USERNAME COUNT(1) ---------
> --------------------- ---------- tc ******1
> 40 tc ******2 60
>
> Then, after a while connection count drops to:
>
> MACHINE USERNAME COUNT(1) ---------
> --------------------- ---------- tc ******1 6
> tc ******2 60
>
>
>
> I have commented all other pools, most fail due to lack of
> resources on database side (hundreeds of connections). Connection
> are opened if pool is defined in context.xml, even if actually not
> used anywhere.
>
> Catalina.out gives me nothing for two pools, bunch of errors with 3
> or more, but those seem to be due to exhaustion of databases
> availability.
>
> Looked up oracle support, nothing of use there. All of this works
> fine with tomcat6, java6, oracle 11g or 12c
So which one of these makes a difference? Tomcat's connection pool
didn't change dramatically between Tomcat 6 and 7. The Java version
likely has nothing to do with it, and the Oracle version also likely
has nothing to do with it.
So what's the problem?
Has your application's user behavior changed in any way? Say, an
increase in traffic?
What you describe sounds an awful lot like poor resource management in
the application itself.
1. Are you sure every part of your application is using your JDBC pools?
2. Read this:
http://blog.christopherschultz.net/index.php/2009/03/16/properly-handling-pooled-jdbc-connections/
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJU7P9wAAoJEBzwKT+lPKRYX/YP/ijgvvieYaNlgaM7cODgPPzm
4GdEyJfXW+xQA5HBOBQemz5CX8YWrSgr9PrlSumf/uU6mx57G1yhmDdmwv1N5jnJ
ct9hBU97aw/6t7FiGF+JPyEjbhETBRIZB5NoOKPiP8CNJeTMd8a9z1Qe6aU1oXMM
yPtsvzg7J5aziKzpdm9xrb0lXtdQe9ga5YfikPShS6Tup1iJzcCImi27RQ6nuUFY
zC8wHVmz0PU8UcbLpFDQGTTUsq6JtQvR/aGpDcHYfq8dNqavnP/QECcx6ZQlixy6
HX30Oj4s/D/I5ez8PXAo2PiSF4ZZ86j0UQt9ntqcDeE7w7ldIfLQ2NCj5jANS6SL
coG3n0tszmVSfCQ3fCXsTphbry0NZSJjNwmkZ4ezXj+3KpD5oATbaTLVL9ZeH9s4
d3HiheNcF//pdeGDZ5Zy09vAO94V9CD+fr2TbbovluHzgpuOu7vYqAwg6IzuMQfs
QWwmiC+Rccp6PnWltSJ7ClIKTh9mDHI7cejdFmQJe4J0kN7HZHggkk7ZlJD5/p6h
sEVxmBZ0JMm0GJzoqOurtHKrviqvbfOJhXd5w6Jmv9Dyj7yK/izhXkACmOp7Rz9K
9/T1OQsyWBtbWho8/xdisEUvsuY9w3lIf2uIeQmikIpICQ4NYddxz5I3/zpd8CSo
KApJwDf0qsXvXduOrANP
=F0TE
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org