Re: Connection leak Tomcat7 and Oracle
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 : > >>> On 26/02/2015 22:56, Christopher Schultz wrote: > >>> > The solution is to put your 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-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: users-h...@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
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 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:ch...@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 : > >>> On 26/02/2015 22:56, Christopher Schultz wrote: > >>> > >>>> The solution is to put your 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-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: users-h...@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. Eve
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 : >>> On 26/02/2015 22:56, Christopher Schultz wrote: >>> The solution is to put your 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-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@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 applicat
Re: Connection leak Tomcat7 and Oracle
On 02/27/2015 06:58 AM, Антон Мацюк wrote: > 2015-02-27 1:36 GMT+02:00 Mark Thomas : >> On 26/02/2015 22:56, Christopher Schultz wrote: >> >>> The solution is to put your 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-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Connection leak Tomcat7 and Oracle
2015-02-27 1:36 GMT+02:00 Mark Thomas : > > On 26/02/2015 22:56, Christopher Schultz wrote: > > > The solution is to put your 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Connection leak Tomcat7 and Oracle
On 26/02/2015 22:56, Christopher Schultz wrote: > The solution is to put your 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Connection leak Tomcat7 and Oracle
-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 :
>>> 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:
>>>
>>> >> 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-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@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 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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Connection leak Tomcat7 and Oracle
On 02/26/2015 12:29 PM, Konstantin Kolinko wrote:
> 2015-02-26 19:28 GMT+03:00 Red :
>> 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:
>>
>>> 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-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Connection leak Tomcat7 and Oracle
2015-02-26 19:28 GMT+03:00 Red :
> 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:
>
> 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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Connection leak Tomcat7 and Oracle
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:
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 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 <
> ch...@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: >>> type="javax.sql.DataSource"
> >>> driverClassName="oracle.jdbc.OracleDriver"
> >>> url="jdbc:oracle:thin:@//*:1521/" minIdle="1"
> >>> username="***" password="***" maxActive="10" maxIdle="10"
> >>> maxWait="-1" /> >>> 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-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
>
Re: Connection leak Tomcat7 and Oracle
Am 24. Februar 2015 22:20:00 MEZ, schrieb Red : >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: > type="javax.sql.DataSource" >driverClassName="oracle.jdbc.OracleDriver" > url="jdbc:oracle:thin:@//*:1521/" >minIdle="1" > username="***" password="***" maxActive="10" >maxIdle="10" maxWait="-1" /> > 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-unsubscr...@tomcat.apache.org >For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Connection leak Tomcat7 and Oracle
unless DBCP changed of course. I would add the following property to your 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 < ch...@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: > type="javax.sql.DataSource" > > driverClassName="oracle.jdbc.OracleDriver" > > url="jdbc:oracle:thin:@//*:1521/" minIdle="1" > > username="***" password="***" maxActive="10" maxIdle="10" > > maxWait="-1" /> > 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-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Connection leak Tomcat7 and Oracle
-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: type="javax.sql.DataSource" > driverClassName="oracle.jdbc.OracleDriver" > url="jdbc:oracle:thin:@//*:1521/" minIdle="1" > username="***" password="***" maxActive="10" maxIdle="10" > maxWait="-1" /> 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Connection leak Tomcat7 and Oracle
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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: 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: JMX Connection "leak"
Thanks On Sun, Mar 13, 2011 at 11:56 AM, Mark Thomas wrote: > On 13/03/2011 08:33, Maimon Oded wrote: > > Hi, > > I'm using tomcat 6 and HypericHQ for monitoring via JMX. > > I don't know if this is an hyperic issue or not, but i wonder if there is > an > > option to fix it via tomcat/java configuration. the reason that i don't > know > > if this is an hyperic or a tomcat/java configuration issue is because > that > > when we use hyperic on other standard java daemon it doesn't have the > same > > connection leak issue. > > That looks like an Hyperic issue to me. > > > the issue is the following: > > hyperic, overtime, opens hundreds of jmx connection and never closes > them.. > > after few hours our tomcat server is using 100% cpu without doing > anything. > > once i stop hyperic agent, tomcat will go back to 0-1% cpu.. > > > > here is what we are seeing virtual vm: > > > http://forums.hyperic.com/jiveforums/servlet/JiveServlet/download/1-11619-37096-2616/Capture.PNG > > > > is there any thing that we can do to fix this via java configuration? > > Not that I am aware of. > > > (forcing it to close a connection that is open for more than X seconds?) > > > > One more thing, in tomcat we see (from time to time) the following > message > > (while hyperic is running): > > Mar 7, 2011 11:30:00 AM ServerCommunicatorAdmin reqIncoming > > WARNING: The server has decided to close this client connection. > > No idea. That is not a Tomcat class. > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -- Oded.
Re: JMX Connection "leak"
On 13/03/2011 08:33, Maimon Oded wrote: > Hi, > I'm using tomcat 6 and HypericHQ for monitoring via JMX. > I don't know if this is an hyperic issue or not, but i wonder if there is an > option to fix it via tomcat/java configuration. the reason that i don't know > if this is an hyperic or a tomcat/java configuration issue is because that > when we use hyperic on other standard java daemon it doesn't have the same > connection leak issue. That looks like an Hyperic issue to me. > the issue is the following: > hyperic, overtime, opens hundreds of jmx connection and never closes them.. > after few hours our tomcat server is using 100% cpu without doing anything. > once i stop hyperic agent, tomcat will go back to 0-1% cpu.. > > here is what we are seeing virtual vm: > http://forums.hyperic.com/jiveforums/servlet/JiveServlet/download/1-11619-37096-2616/Capture.PNG > > is there any thing that we can do to fix this via java configuration? Not that I am aware of. > (forcing it to close a connection that is open for more than X seconds?) > > One more thing, in tomcat we see (from time to time) the following message > (while hyperic is running): > Mar 7, 2011 11:30:00 AM ServerCommunicatorAdmin reqIncoming > WARNING: The server has decided to close this client connection. No idea. That is not a Tomcat class. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
JMX Connection "leak"
Hi, I'm using tomcat 6 and HypericHQ for monitoring via JMX. I don't know if this is an hyperic issue or not, but i wonder if there is an option to fix it via tomcat/java configuration. the reason that i don't know if this is an hyperic or a tomcat/java configuration issue is because that when we use hyperic on other standard java daemon it doesn't have the same connection leak issue. the issue is the following: hyperic, overtime, opens hundreds of jmx connection and never closes them.. after few hours our tomcat server is using 100% cpu without doing anything. once i stop hyperic agent, tomcat will go back to 0-1% cpu.. here is what we are seeing virtual vm: http://forums.hyperic.com/jiveforums/servlet/JiveServlet/download/1-11619-37096-2616/Capture.PNG is there any thing that we can do to fix this via java configuration? (forcing it to close a connection that is open for more than X seconds?) One more thing, in tomcat we see (from time to time) the following message (while hyperic is running): Mar 7, 2011 11:30:00 AM ServerCommunicatorAdmin reqIncoming WARNING: The server has decided to close this client connection. Any help will be great.. Thanks. Oded. -- Oded.
RE: Connection Leak
I had a bit of a leak, and it stopped them...actually an error coupled with a leak. You might check with some of the other users -- I think they've recommended Lamda Probe and some other tools to track down leaks. -Original Message- From: Ziggy [mailto:zigg...@gmail.com] Sent: Wednesday, November 03, 2010 11:19 AM To: Tomcat Users List Subject: Re: Connection Leak Does that show cached queries? On Wed, Nov 3, 2010 at 4:02 PM, Propes, Barry L wrote: > Maybe try adding this, too as an attribute in the Resource tag. > > timeBetweenEvictionRunsMillis="-1" > > -Original Message- > From: Jason Britton [mailto:jbritto...@gmail.com] > Sent: Wednesday, November 03, 2010 9:05 AM > To: Tomcat Users List > Subject: Re: Connection Leak > > Since you're using an Oracle database - another way to identify areas > in your code that aren't closing connections. In the sql below > substitute YOURDBUSER with the name of the database user your > connections connect to your database with and YOURWEBSERVER with the > name of your webserver. The results of the sql query will give you > the last executed sql for each of the open connections. Then search > your code for where this sql is being executed and double check you are > closing the connection appropriately. > > SELECT username, machine, oc.sql_text, COUNT(*) open_statements FROM > v$session vs, v$open_cursor oc WHERE username = 'YOURDBUSER' AND > machine = 'YOURWEBSERVER' AND oc.sid = vs.sid GROUP BY username, > machine, oc.sql_text ORDER BY open_statements DESC > > > > On Wed, Nov 3, 2010 at 6:44 AM, Ziggy wrote: > > > Hi All, > > > > > type="javax.sql.DataSource" > > driverClassName="oracle.jdbc.driver.OracleDriver" > > url="jdbc:oracle:thin:@10.10.10.10.:1521:mydb" > > username="username" password="password" maxActive="500" > > maxIdle="50" > > maxWait="-1" removeAbandoned="true" > > removeAbandonedTimeout="60" logAbandoned="true" > > accessToUnderlyingConnectionAllowed="true" > > /> > > > > I am trying to find out areas of the application where connections > > are NOT being closed. I added the removeAbandoned and logAbandoned > > clauses in my context file but if i check v$session on oracle it is > > still showing the same number of connections active even after 60 seconds. > > Is there something wrong in the configuration above? > > > > > > How exactly does it abandone the connections? what triggers it>? > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Connection Leak
Does that show cached queries? On Wed, Nov 3, 2010 at 4:02 PM, Propes, Barry L wrote: > Maybe try adding this, too as an attribute in the Resource tag. > > timeBetweenEvictionRunsMillis="-1" > > -Original Message- > From: Jason Britton [mailto:jbritto...@gmail.com] > Sent: Wednesday, November 03, 2010 9:05 AM > To: Tomcat Users List > Subject: Re: Connection Leak > > Since you're using an Oracle database - another way to identify areas in > your code that aren't closing connections. In the sql below substitute > YOURDBUSER with the name of the database user your connections connect to > your database with and YOURWEBSERVER with the name of your webserver. The > results of the sql query will give you the last executed sql for each of the > open connections. Then search your code for where this sql is being > executed and double check you are closing the connection appropriately. > > SELECT username, machine, oc.sql_text, COUNT(*) open_statements FROM > v$session vs, v$open_cursor oc WHERE username = 'YOURDBUSER' AND machine = > 'YOURWEBSERVER' AND oc.sid = vs.sid GROUP BY username, machine, oc.sql_text > ORDER BY open_statements DESC > > > > On Wed, Nov 3, 2010 at 6:44 AM, Ziggy wrote: > > > Hi All, > > > > > type="javax.sql.DataSource" > > driverClassName="oracle.jdbc.driver.OracleDriver" > > url="jdbc:oracle:thin:@10.10.10.10.:1521:mydb" > > username="username" password="password" maxActive="500" > > maxIdle="50" > > maxWait="-1" removeAbandoned="true" > > removeAbandonedTimeout="60" logAbandoned="true" > > accessToUnderlyingConnectionAllowed="true" > > /> > > > > I am trying to find out areas of the application where connections are > > NOT being closed. I added the removeAbandoned and logAbandoned clauses > > in my context file but if i check v$session on oracle it is still > > showing the same number of connections active even after 60 seconds. > > Is there something wrong in the configuration above? > > > > > > How exactly does it abandone the connections? what triggers it>? > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
RE: Connection Leak
Maybe try adding this, too as an attribute in the Resource tag. timeBetweenEvictionRunsMillis="-1" -Original Message- From: Jason Britton [mailto:jbritto...@gmail.com] Sent: Wednesday, November 03, 2010 9:05 AM To: Tomcat Users List Subject: Re: Connection Leak Since you're using an Oracle database - another way to identify areas in your code that aren't closing connections. In the sql below substitute YOURDBUSER with the name of the database user your connections connect to your database with and YOURWEBSERVER with the name of your webserver. The results of the sql query will give you the last executed sql for each of the open connections. Then search your code for where this sql is being executed and double check you are closing the connection appropriately. SELECT username, machine, oc.sql_text, COUNT(*) open_statements FROM v$session vs, v$open_cursor oc WHERE username = 'YOURDBUSER' AND machine = 'YOURWEBSERVER' AND oc.sid = vs.sid GROUP BY username, machine, oc.sql_text ORDER BY open_statements DESC On Wed, Nov 3, 2010 at 6:44 AM, Ziggy wrote: > Hi All, > > type="javax.sql.DataSource" > driverClassName="oracle.jdbc.driver.OracleDriver" > url="jdbc:oracle:thin:@10.10.10.10.:1521:mydb" > username="username" password="password" maxActive="500" > maxIdle="50" > maxWait="-1" removeAbandoned="true" > removeAbandonedTimeout="60" logAbandoned="true" > accessToUnderlyingConnectionAllowed="true" > /> > > I am trying to find out areas of the application where connections are > NOT being closed. I added the removeAbandoned and logAbandoned clauses > in my context file but if i check v$session on oracle it is still > showing the same number of connections active even after 60 seconds. > Is there something wrong in the configuration above? > > > How exactly does it abandone the connections? what triggers it>? > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Connection Leak
Since you're using an Oracle database - another way to identify areas in your code that aren't closing connections. In the sql below substitute YOURDBUSER with the name of the database user your connections connect to your database with and YOURWEBSERVER with the name of your webserver. The results of the sql query will give you the last executed sql for each of the open connections. Then search your code for where this sql is being executed and double check you are closing the connection appropriately. SELECT username, machine, oc.sql_text, COUNT(*) open_statements FROM v$session vs, v$open_cursor oc WHERE username = 'YOURDBUSER' AND machine = 'YOURWEBSERVER' AND oc.sid = vs.sid GROUP BY username, machine, oc.sql_text ORDER BY open_statements DESC On Wed, Nov 3, 2010 at 6:44 AM, Ziggy wrote: > Hi All, > > type="javax.sql.DataSource" > driverClassName="oracle.jdbc.driver.OracleDriver" > url="jdbc:oracle:thin:@10.10.10.10.:1521:mydb" > username="username" password="password" maxActive="500" > maxIdle="50" > maxWait="-1" removeAbandoned="true" > removeAbandonedTimeout="60" logAbandoned="true" > accessToUnderlyingConnectionAllowed="true" > /> > > I am trying to find out areas of the application where connections are NOT > being closed. I added the removeAbandoned and logAbandoned clauses in my > context file but if i check v$session on oracle it is still showing the > same > number of connections active even after 60 seconds. Is there something > wrong > in the configuration above? > > > How exactly does it abandone the connections? what triggers it>? >
Re: Connection Leak
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ziggy, On 11/3/2010 9:44 AM, Ziggy wrote: > Hi All, > >type="javax.sql.DataSource" > driverClassName="oracle.jdbc.driver.OracleDriver" > url="jdbc:oracle:thin:@10.10.10.10.:1521:mydb" > username="username" password="password" maxActive="500" > maxIdle="50" > maxWait="-1" removeAbandoned="true" > removeAbandonedTimeout="60" logAbandoned="true" > accessToUnderlyingConnectionAllowed="true" > /> > > I am trying to find out areas of the application where connections are NOT > being closed. I added the removeAbandoned and logAbandoned clauses in my > context file but if i check v$session on oracle it is still showing the same > number of connections active even after 60 seconds. Is there something wrong > in the configuration above? Tip: try setting maxActive="1" in development. You'll run across connection leaks much faster that way. > How exactly does it abandone the connections? what triggers it>? Read (the end of the) configuration docs for commons-dbcp, which is the basis for connection pooling in Tomcat: http://commons.apache.org/dbcp/configuration.html - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzRaN8ACgkQ9CaO5/Lv0PDstgCfYQAuiuuVkY2Rn8yb5S9sejNI SUcAn0ZeJN6rceOFscp8DncfdReqSAYK =QFUQ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Connection Leak
Hi All, I am trying to find out areas of the application where connections are NOT being closed. I added the removeAbandoned and logAbandoned clauses in my context file but if i check v$session on oracle it is still showing the same number of connections active even after 60 seconds. Is there something wrong in the configuration above? How exactly does it abandone the connections? what triggers it>?
Re: Connection Leak in java - Tomcat 6.0.18
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Arun, Arun Raj Ramkumar wrote: > Hi friends, > Please let me know is there a way to find out connection leak in my java > code , when its deployed in tomcat. Am using tomcat 6.0.18 What type of connection? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkbM28ACgkQ9CaO5/Lv0PCW8wCfT5sUBsISbomP9/+NB8M1clXH XUYAn2M0BSRPOQaNi+AwE4kruF81xODN =0NRI -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Connection Leak in java - Tomcat 6.0.18
Hi friends, Please let me know is there a way to find out connection leak in my java code , when its deployed in tomcat. Am using tomcat 6.0.18 Regards, Arun.
Re: Diagnosing DBCP JDBC connection leak using removeAbandoned parm
Richard Mixon wrote: Marc, Thank you - We are using a recent version of the MySQL Connector/J (3.1.10), but maybe that does not mean anything. - Richard Hmm thats not very recent. I know of 2 bugs since then that have bitten me. 3.1.13 should be brewing and that would be the first release to resolve both. I have not read the details of your problem but around 12 months ago I had a problem with connection pooling and MySQL driver, in that the connection pool wasn't working. The connection pooler did not take already open connections from out the pool first before opening new connections (it did this to the point of creating 100+ connections during simple testing where a single http client ran at a time). Also during a web-app restart those already open connections in the pool were never reclaimed and remained open between the JVM and MySQL server. I never got to the bottom of the problem, I just upgraded everything and added some utility functions to my contextDestroyed() web-app lifecycle method. Maybe useful links for this: http://forum.hibernate.org/viewtopic.php?t=935948&start=150 HTH -- Darryl L. Miles - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Diagnosing DBCP JDBC connection leak using removeAbandoned parm - short version
#1 Could be a logging bug. Notice how the day is always the same as the minute. On 4/5/06, Richard Mixon <[EMAIL PROTECTED]> wrote: > > I'm still curious about the crazy logAbandoned messages - not sure how to > interpret or rely on them. I'll try a again with a briefer posting - maybe > I > was too detailed in the original post. > > We are getting strange (erroneous?) messages because of the logAbandoned > parameter: > > 1) The dates look like they are from lalaland (e.g. a date of > April 34,2006 in the second line below). > Maybe I do not understand how remove abandoned is working - the > timeout is supposed to start once a connection is determined to be > "idle". > 2) Second the abandoned objects do not appear to be in order - > they jump from 10:23 to 13:34, 13:01, 13:35, back to 10:29 (see > below). > > Here is an extract/grep from our catalina.out: > DBCP object created 2006-23-04 10:23:35 by the following code was never > closed: > DBCP object created 2006-34-04 13:34:55 by the following code was never > closed: > DBCP object created 2006-01-04 13:01:49 by the following code was never > closed: > DBCP object created 2006-35-04 13:35:00 by the following code was never > closed: > DBCP object created 2006-29-04 10:29:21 by the following code was never > closed: > DBCP object created 2006-36-04 13:36:39 by the following code was never > closed: > DBCP object created 2006-23-04 10:23:35 by the following code was never > closed: > DBCP object created 2006-36-04 13:36:43 by the following code was never > closed: > DBCP object created 2006-01-04 13:01:49 by the following code was never > closed: > DBCP object created 2006-36-04 13:36:56 by the following code was never > closed: > DBCP object created 2006-40-04 13:40:30 by the following code was never > closed: > DBCP object created 2006-15-04 15:15:02 by the following code was never > closed: > DBCP object created 2006-15-04 15:15:02 by the following code was never > closed: > DBCP object created 2006-11-04 14:11:46 by the following code was never > closed: > DBCP object created 2006-00-04 16:00:01 by the following code was never > closed: > DBCP object created 2006-00-04 16:00:01 by the following code was never > closed: > DBCP object created 2006-39-04 13:39:55 by the following code was never > closed: > DBCP object created 2006-00-04 16:00:02 by the following code was never > closed: > DBCP object created 2006-00-04 16:00:02 by the following code was never > closed: > DBCP object created 2006-11-04 14:11:46 by the following code was never > closed: > DBCP object created 2006-26-04 16:26:18 by the following code was never > closed: > DBCP object created 2006-26-04 16:26:18 by the following code was never > closed: > DBCP object created 2006-26-04 16:26:18 by the following code was never > closed: > > And, here's the relevant portion of our server.xml: >appBase="/home/httpd/vhosts/acme.com"> > www.acme.com > directory="logs" prefix="acme.com_log." > suffix=".txt" > timestamp="true"/> > > type="javax.sql.DataSource"/> > > > url > > > jdbc:mysql://localhost/acme?autoReconnect=true&zeroDateTimeBehavi > or=convertToNull&noDatetimeStringSync=true > > > driverClassName > com.mysql.jdbc.Driver > > > > username > acme > > > password > secret > > > removeAbandoned > true > > > removeAbandonedTimeout > 60 > > > logAbandoned > true > > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Diagnosing DBCP JDBC connection leak using removeAbandoned parm
Sorry, I didn't take a very close look at this when you originally
posted it. Taking a look at your original code:
Connection conn = new Connector().CreateConnection();
Statement stmt=null;
ResultSet rset=null;
try {
String open_total = "-100";
stmt = conn.createStatement();
rset = stmt.executeQuery ("select count(OPEN_MAIL_MEMBER_ID) from
OPEN_MAIL where OPEN_MAIL_MEMBER_ID="+memberid);
while (rset.next()) {
open_total = rset.getString(1);
}
stmt = conn.createStatement();
stmt.executeUpdate ("update EMAIL_ADDR set
OPEN_MAIL_TOTAL="+open_total+" where EMAIL_ADDR_ID="+memberid);
} catch (Exception e) {
SharedUtilities.logError(e);
} finally {
try {
rset.close();
stmt.close();
conn.close();
} catch (Exception e) {
SharedUtilities.logError(e);
}
}
Shot in the dark here, but you might want to try explicitly closing your
result set and first statement before attempting to open a new
statement. Either that or use a different variable for your second
statement and then close them both in the finally block.
--David
Richard Mixon wrote:
Marc,
Thank you - We are using a recent version of the MySQL Connector/J (3.1.10),
but maybe that does not mean anything.
- Richard
-Original Message-
From: Farrow, Marc [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 05, 2006 4:44 AM
To: Tomcat Users List
Subject: RE: Diagnosing DBCP JDBC connection leak using removeAbandoned parm
Can you change your code to something similar to below? I have seen issues
with certain implementations of database drivers in which the JDBC
interfaces are not being implemented/coded properly.
Just remember that the order you call your close statements does matter
(although yours looked correct).
Hth
Marc
Connection conn = new Connector().CreateConnection();
Statement stmt=null;
ResultSet rset=null;
try {
String open_total = "-100";
stmt = conn.createStatement();
rset = stmt.executeQuery ("select count(OPEN_MAIL_MEMBER_ID) from
OPEN_MAIL where OPEN_MAIL_MEMBER_ID="+memberid);
while (rset.next()) {
open_total = rset.getString(1);
}
stmt = conn.createStatement();
stmt.executeUpdate ("update EMAIL_ADDR set
OPEN_MAIL_TOTAL="+open_total+" where EMAIL_ADDR_ID="+memberid);
rset.close();
rset = null;
stmt.close();
stmt = null;
conn.close();
conn = null;
} catch (Exception e) {
SharedUtilities.logError(e);
} finally {
try {
if (rset != null) {
rset.close();
}
catch (SQLException e) {
//Exception ignored
}
try {
if (stmt != null) {
stmt.close();
}
catch (SQLException e) {
//Exception ignored
}
try {
if (conn != null) {
conn.close();
}
catch (SQLException e) {
//Exception ignored
}
}
-Original Message-
From: Richard Mixon [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 04, 2006 10:57 PM
To: users@tomcat.apache.org
Subject: Diagnosing DBCP JDBC connection leak using removeAbandoned parm
Bear with me, I'll try to make this short, but want to give enough
info/background that it makes sense. Basically we are a bit confused by the
output of the DBCP logAbandoned parameter. Any help is appreciated.
Environment: We are using Tomcat 4.1.18 (for now), MySQL 4.0.18, Java
1.5.0_04-b05, all running under Linux kernel 2.4.22-1.2115.nptlsmp on a dual
Xeon dedicated server.
Anyway, we determined that we had a connection leak when our application
froze today. We obtained a thread dump and it showed that everyone of the
Tomcat threads that were running application code, were waiting to get a
connection from the DBCP pool.
Each process looked something like this in the thread dump:
"Thread-171" daemon prio=1 tid=0x8a88a528 nid=0x46e9 in Object.wait()
[0x9559f000..0x955a0700]
at java.lang.Object.wait(Native Method)
- waiting on <0x4a08cb78> (a
org.apache.commons.dbcp.AbandonedObjectPool)
at java.lang.Object.wait(Object.java:474)
at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(Unknown
Source)
- locked <0x4a08cb78> (a org.apache.commons.dbcp.AbandonedObjectPool)
at
org.apache.commons.dbcp.AbandonedObjectPool.borrowObject(AbandonedObjectPool
.java:117)
- locked <0x4a08cb78> (a org.apache.commons.dbcp.AbandonedObjectPool)
at
org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.ja
va:110)
at
org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:3
12)
at com.acme.Connector.CreateConnection(Connector.java:56)
at com.acme.OpenMailData.insert(OpenMailData.java:282)
at com.acme.trackopenmail.doPost(trackopenmail.java:127)
at com.acme.trackopenmail.doGet(trackopenmail.java:65)
at java
RE: Diagnosing DBCP JDBC connection leak using removeAbandoned parm
Marc,
Thank you - We are using a recent version of the MySQL Connector/J (3.1.10),
but maybe that does not mean anything.
- Richard
-Original Message-
From: Farrow, Marc [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 05, 2006 4:44 AM
To: Tomcat Users List
Subject: RE: Diagnosing DBCP JDBC connection leak using removeAbandoned parm
Can you change your code to something similar to below? I have seen issues
with certain implementations of database drivers in which the JDBC
interfaces are not being implemented/coded properly.
Just remember that the order you call your close statements does matter
(although yours looked correct).
Hth
Marc
Connection conn = new Connector().CreateConnection();
Statement stmt=null;
ResultSet rset=null;
try {
String open_total = "-100";
stmt = conn.createStatement();
rset = stmt.executeQuery ("select count(OPEN_MAIL_MEMBER_ID) from
OPEN_MAIL where OPEN_MAIL_MEMBER_ID="+memberid);
while (rset.next()) {
open_total = rset.getString(1);
}
stmt = conn.createStatement();
stmt.executeUpdate ("update EMAIL_ADDR set
OPEN_MAIL_TOTAL="+open_total+" where EMAIL_ADDR_ID="+memberid);
rset.close();
rset = null;
stmt.close();
stmt = null;
conn.close();
conn = null;
} catch (Exception e) {
SharedUtilities.logError(e);
} finally {
try {
if (rset != null) {
rset.close();
}
catch (SQLException e) {
//Exception ignored
}
try {
if (stmt != null) {
stmt.close();
}
catch (SQLException e) {
//Exception ignored
}
try {
if (conn != null) {
conn.close();
}
catch (SQLException e) {
//Exception ignored
}
}
-Original Message-
From: Richard Mixon [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 04, 2006 10:57 PM
To: users@tomcat.apache.org
Subject: Diagnosing DBCP JDBC connection leak using removeAbandoned parm
Bear with me, I'll try to make this short, but want to give enough
info/background that it makes sense. Basically we are a bit confused by the
output of the DBCP logAbandoned parameter. Any help is appreciated.
Environment: We are using Tomcat 4.1.18 (for now), MySQL 4.0.18, Java
1.5.0_04-b05, all running under Linux kernel 2.4.22-1.2115.nptlsmp on a dual
Xeon dedicated server.
Anyway, we determined that we had a connection leak when our application
froze today. We obtained a thread dump and it showed that everyone of the
Tomcat threads that were running application code, were waiting to get a
connection from the DBCP pool.
Each process looked something like this in the thread dump:
"Thread-171" daemon prio=1 tid=0x8a88a528 nid=0x46e9 in Object.wait()
[0x9559f000..0x955a0700]
at java.lang.Object.wait(Native Method)
- waiting on <0x4a08cb78> (a
org.apache.commons.dbcp.AbandonedObjectPool)
at java.lang.Object.wait(Object.java:474)
at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(Unknown
Source)
- locked <0x4a08cb78> (a org.apache.commons.dbcp.AbandonedObjectPool)
at
org.apache.commons.dbcp.AbandonedObjectPool.borrowObject(AbandonedObjectPool
.java:117)
- locked <0x4a08cb78> (a org.apache.commons.dbcp.AbandonedObjectPool)
at
org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.ja
va:110)
at
org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:3
12)
at com.acme.Connector.CreateConnection(Connector.java:56)
at com.acme.OpenMailData.insert(OpenMailData.java:282)
at com.acme.trackopenmail.doPost(trackopenmail.java:127)
at com.acme.trackopenmail.doGet(trackopenmail.java:65)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application
FilterChain.java:247)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh
ain.java:193)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja
va:260)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja
va:191)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2415)
at
org.apache.c
RE: Diagnosing DBCP JDBC connection leak using removeAbandoned parm - short version
I'm still curious about the crazy logAbandoned messages - not sure how to interpret or rely on them. I'll try a again with a briefer posting - maybe I was too detailed in the original post. We are getting strange (erroneous?) messages because of the logAbandoned parameter: 1) The dates look like they are from lalaland (e.g. a date of April 34,2006 in the second line below). Maybe I do not understand how remove abandoned is working - the timeout is supposed to start once a connection is determined to be "idle". 2) Second the abandoned objects do not appear to be in order - they jump from 10:23 to 13:34, 13:01, 13:35, back to 10:29 (see below). Here is an extract/grep from our catalina.out: DBCP object created 2006-23-04 10:23:35 by the following code was never closed: DBCP object created 2006-34-04 13:34:55 by the following code was never closed: DBCP object created 2006-01-04 13:01:49 by the following code was never closed: DBCP object created 2006-35-04 13:35:00 by the following code was never closed: DBCP object created 2006-29-04 10:29:21 by the following code was never closed: DBCP object created 2006-36-04 13:36:39 by the following code was never closed: DBCP object created 2006-23-04 10:23:35 by the following code was never closed: DBCP object created 2006-36-04 13:36:43 by the following code was never closed: DBCP object created 2006-01-04 13:01:49 by the following code was never closed: DBCP object created 2006-36-04 13:36:56 by the following code was never closed: DBCP object created 2006-40-04 13:40:30 by the following code was never closed: DBCP object created 2006-15-04 15:15:02 by the following code was never closed: DBCP object created 2006-15-04 15:15:02 by the following code was never closed: DBCP object created 2006-11-04 14:11:46 by the following code was never closed: DBCP object created 2006-00-04 16:00:01 by the following code was never closed: DBCP object created 2006-00-04 16:00:01 by the following code was never closed: DBCP object created 2006-39-04 13:39:55 by the following code was never closed: DBCP object created 2006-00-04 16:00:02 by the following code was never closed: DBCP object created 2006-00-04 16:00:02 by the following code was never closed: DBCP object created 2006-11-04 14:11:46 by the following code was never closed: DBCP object created 2006-26-04 16:26:18 by the following code was never closed: DBCP object created 2006-26-04 16:26:18 by the following code was never closed: DBCP object created 2006-26-04 16:26:18 by the following code was never closed: And, here's the relevant portion of our server.xml: www.acme.com url jdbc:mysql://localhost/acme?autoReconnect=true&zeroDateTimeBehavi or=convertToNull&noDatetimeStringSync=true driverClassName com.mysql.jdbc.Driver username acme password secret removeAbandoned true removeAbandonedTimeout 60 logAbandoned true - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Diagnosing DBCP JDBC connection leak using removeAbandoned parm
Can you change your code to something similar to below? I have seen issues
with certain implementations of database drivers in which the JDBC interfaces
are not being implemented/coded properly.
Just remember that the order you call your close statements does matter
(although yours looked correct).
Hth
Marc
Connection conn = new Connector().CreateConnection();
Statement stmt=null;
ResultSet rset=null;
try {
String open_total = "-100";
stmt = conn.createStatement();
rset = stmt.executeQuery ("select count(OPEN_MAIL_MEMBER_ID) from
OPEN_MAIL where OPEN_MAIL_MEMBER_ID="+memberid);
while (rset.next()) {
open_total = rset.getString(1);
}
stmt = conn.createStatement();
stmt.executeUpdate ("update EMAIL_ADDR set
OPEN_MAIL_TOTAL="+open_total+" where EMAIL_ADDR_ID="+memberid);
rset.close();
rset = null;
stmt.close();
stmt = null;
conn.close();
conn = null;
} catch (Exception e) {
SharedUtilities.logError(e);
} finally {
try {
if (rset != null) {
rset.close();
}
catch (SQLException e) {
//Exception ignored
}
try {
if (stmt != null) {
stmt.close();
}
catch (SQLException e) {
//Exception ignored
}
try {
if (conn != null) {
conn.close();
}
catch (SQLException e) {
//Exception ignored
}
}
-Original Message-
From: Richard Mixon [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 04, 2006 10:57 PM
To: users@tomcat.apache.org
Subject: Diagnosing DBCP JDBC connection leak using removeAbandoned parm
Bear with me, I'll try to make this short, but want to give enough
info/background that it makes sense. Basically we are a bit confused by the
output of the DBCP logAbandoned parameter. Any help is appreciated.
Environment: We are using Tomcat 4.1.18 (for now), MySQL 4.0.18, Java
1.5.0_04-b05, all running under Linux kernel 2.4.22-1.2115.nptlsmp on a dual
Xeon dedicated server.
Anyway, we determined that we had a connection leak when our application
froze today. We obtained a thread dump and it showed that everyone of the
Tomcat threads that were running application code, were waiting to get a
connection from the DBCP pool.
Each process looked something like this in the thread dump:
"Thread-171" daemon prio=1 tid=0x8a88a528 nid=0x46e9 in Object.wait()
[0x9559f000..0x955a0700]
at java.lang.Object.wait(Native Method)
- waiting on <0x4a08cb78> (a
org.apache.commons.dbcp.AbandonedObjectPool)
at java.lang.Object.wait(Object.java:474)
at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(Unknown
Source)
- locked <0x4a08cb78> (a org.apache.commons.dbcp.AbandonedObjectPool)
at
org.apache.commons.dbcp.AbandonedObjectPool.borrowObject(AbandonedObjectPool
.java:117)
- locked <0x4a08cb78> (a org.apache.commons.dbcp.AbandonedObjectPool)
at
org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.ja
va:110)
at
org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:3
12)
at com.acme.Connector.CreateConnection(Connector.java:56)
at com.acme.OpenMailData.insert(OpenMailData.java:282)
at com.acme.trackopenmail.doPost(trackopenmail.java:127)
at com.acme.trackopenmail.doGet(trackopenmail.java:65)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application
FilterChain.java:247)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh
ain.java:193)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja
va:260)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja
va:191)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2415)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180
)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(StandardPipeline.java:643)
at
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.
java:170)
at
org.apache.catalina.core.StandardPipeline$S
Diagnosing DBCP JDBC connection leak using removeAbandoned parm
Bear with me, I'll try to make this short, but want to give enough info/background that it makes sense. Basically we are a bit confused by the output of the DBCP logAbandoned parameter. Any help is appreciated. Environment: We are using Tomcat 4.1.18 (for now), MySQL 4.0.18, Java 1.5.0_04-b05, all running under Linux kernel 2.4.22-1.2115.nptlsmp on a dual Xeon dedicated server. Anyway, we determined that we had a connection leak when our application froze today. We obtained a thread dump and it showed that everyone of the Tomcat threads that were running application code, were waiting to get a connection from the DBCP pool. Each process looked something like this in the thread dump: "Thread-171" daemon prio=1 tid=0x8a88a528 nid=0x46e9 in Object.wait() [0x9559f000..0x955a0700] at java.lang.Object.wait(Native Method) - waiting on <0x4a08cb78> (a org.apache.commons.dbcp.AbandonedObjectPool) at java.lang.Object.wait(Object.java:474) at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(Unknown Source) - locked <0x4a08cb78> (a org.apache.commons.dbcp.AbandonedObjectPool) at org.apache.commons.dbcp.AbandonedObjectPool.borrowObject(AbandonedObjectPool .java:117) - locked <0x4a08cb78> (a org.apache.commons.dbcp.AbandonedObjectPool) at org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.ja va:110) at org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:3 12) at com.acme.Connector.CreateConnection(Connector.java:56) at com.acme.OpenMailData.insert(OpenMailData.java:282) at com.acme.trackopenmail.doPost(trackopenmail.java:127) at com.acme.trackopenmail.doGet(trackopenmail.java:65) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application FilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh ain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja va:260) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok eNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja va:191) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok eNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2415) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180 ) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok eNext(StandardPipeline.java:643) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve. java:170) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok eNext(StandardPipeline.java:641) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172 ) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok eNext(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java :174) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok eNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:261) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:360) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:632) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:590) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:707) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav a:530) at java.lang.Thread.run(Thread.java:595) So, we decided to change our removeAbandonedTimeout to 60 (from the default of 300 seconds) and also to supply the parameter logAbandoned=true for DBCP. So far, this seems to have "helped" the situation, but we realize that the real problem is that connections are not being properly closed and this is only giving us a bit of breathing
Re: DBCP connection leak after undeploy
Correct.
On 10/31/05, Steve Kirk <[EMAIL PROTECTED]> wrote:
>
> I was thinking that you could write your own ServletContextListener code to
> create/close the pool, so that you do not have to rely on TC to manage DBCP
> via JNDI. I am planning to do this myself sometime soon, for other reasons
> (you've just given me another one). I'm thinking that by not using JNDI, I
> would not encounter of the problem you mention below, because the problem is
> related to the TC-JNDI interface. Does that sound right to you?
>
> > -Original Message-
> > From: Bogdan Calmac [mailto:[EMAIL PROTECTED]
> > Sent: Monday 31 October 2005 16:50
> > To: Tomcat Users List
> > Subject: Re: DBCP connection leak after undeploy
> >
> >
> > In our company we share several Tomcat servers for all developers, so
> > that's why we use deploy/undeploy instead of start/stop.
> >
> > As a workaround for this problem, you can create a
> > ServletContextListener and close the datasource yourself in
> > contextDestroyed(). I used refection here to avoid compile time
> > dependency on Tomcat DBCP.
> >
> > try
> > {
> > Context initCtx = new InitialContext();
> > ds = (DataSource)
> > initCtx.lookup("java:comp/env/jdbc/YourDSName");
> > if ("org.apache.tomcat.dbcp.dbcp.BasicDataSource".equals(
> > ds.getClass().getName()))
> > {
> > Method closeMethod = ds.getClass().getMethod("close");
> > closeMethod.invoke(ds);
> > }
> > catch (Exception e)
> > {
> > yourLog.error("Failed to close DBCP DataSource.", e);
> > }
> >
> > The above code would actually not work because JNDI is destroyed by
> > the time contextDestroyed() is called (see
> > http://issues.apache.org/bugzilla/show_bug.cgi?id=37264) so you could
> > do the lookup and cache the datasource object in contextInitialized().
> >
> > On 10/28/05, Steve Kirk <[EMAIL PROTECTED]> wrote:
> > > Yes, confirmed, I get the same problem. (I used the
> > undeploy command from
> > > within the NetBeans runtime window, and also checked using
> > the undeploy link
> > > in the browser from /manager/html/). Conns are cleaned up OK if you
> > > start/stop TC, but not if you undeploy the app with TC
> > still running, as you
> > > said.
> > >
> > > Having said that, does anyone undeploy apps like this on
> > production servers?
> > > I wouldn't think so, but then again I suppose it might
> > affect ISP type
> > > users.
> > >
> > > PS I have these config values:
> > > maxActive="10"
> > > maxIdle="5"
> > >
> > > > -Original Message-
> > > > From: Bogdan Calmac [mailto:[EMAIL PROTECTED]
> > > > Sent: Thursday 27 October 2005 19:27
> > > > To: Tomcat Users List
> > > > Subject: Re: DBCP connection leak after undeploy
> > > >
> > > >
> > > > > PS I don't think that I have see the problem that you have
> > > > reported. I run
> > > > > TC 5.5.9 on WinXP with Mysql 4.1.11 and Connector/J 3.1.8,
> > > > have never
> > > > > noticed that problem, my pools always seem to clean up fine.
> > > >
> > > > You might not have the same setup. I would suggest to try the
> > > > following:
> > > >
> > > > 1. make sure you define the datasource in
> > META-INF/context.xml and you
> > > > access the DB using that JNDI datasource.
> > > > 2. package your webapp as a war
> > > > 3. Do a "netstat" and note how many DB connections are open
> > > > 4. deploy your webapp using the ant task or the manager webapp
> > > > 5. Access your webapp to use the DB
> > > > 6. Do another "netstat" to confirm that there is one more DB
> > > > connection (which is now pooled)
> > > > 7. undeploy your webapp using the ant task or the manager
> > webapp (do
> > > > not stop tomcat)
> > > > 8. Do one more "netstat" and I would be very surprised if
> > the extra
> > > > connection was closed :-)
> > > >
> > > > Another explanation for your finding could be setting
> > maxIdle="0" in
> > > > the resource definition, but that practically disables pooling.
> > > >
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: DBCP connection leak after undeploy
I was thinking that you could write your own ServletContextListener code to
create/close the pool, so that you do not have to rely on TC to manage DBCP
via JNDI. I am planning to do this myself sometime soon, for other reasons
(you've just given me another one). I'm thinking that by not using JNDI, I
would not encounter of the problem you mention below, because the problem is
related to the TC-JNDI interface. Does that sound right to you?
> -Original Message-
> From: Bogdan Calmac [mailto:[EMAIL PROTECTED]
> Sent: Monday 31 October 2005 16:50
> To: Tomcat Users List
> Subject: Re: DBCP connection leak after undeploy
>
>
> In our company we share several Tomcat servers for all developers, so
> that's why we use deploy/undeploy instead of start/stop.
>
> As a workaround for this problem, you can create a
> ServletContextListener and close the datasource yourself in
> contextDestroyed(). I used refection here to avoid compile time
> dependency on Tomcat DBCP.
>
> try
> {
> Context initCtx = new InitialContext();
> ds = (DataSource)
> initCtx.lookup("java:comp/env/jdbc/YourDSName");
> if ("org.apache.tomcat.dbcp.dbcp.BasicDataSource".equals(
> ds.getClass().getName()))
> {
> Method closeMethod = ds.getClass().getMethod("close");
> closeMethod.invoke(ds);
> }
> catch (Exception e)
> {
> yourLog.error("Failed to close DBCP DataSource.", e);
> }
>
> The above code would actually not work because JNDI is destroyed by
> the time contextDestroyed() is called (see
> http://issues.apache.org/bugzilla/show_bug.cgi?id=37264) so you could
> do the lookup and cache the datasource object in contextInitialized().
>
> On 10/28/05, Steve Kirk <[EMAIL PROTECTED]> wrote:
> > Yes, confirmed, I get the same problem. (I used the
> undeploy command from
> > within the NetBeans runtime window, and also checked using
> the undeploy link
> > in the browser from /manager/html/). Conns are cleaned up OK if you
> > start/stop TC, but not if you undeploy the app with TC
> still running, as you
> > said.
> >
> > Having said that, does anyone undeploy apps like this on
> production servers?
> > I wouldn't think so, but then again I suppose it might
> affect ISP type
> > users.
> >
> > PS I have these config values:
> > maxActive="10"
> > maxIdle="5"
> >
> > > -Original Message-
> > > From: Bogdan Calmac [mailto:[EMAIL PROTECTED]
> > > Sent: Thursday 27 October 2005 19:27
> > > To: Tomcat Users List
> > > Subject: Re: DBCP connection leak after undeploy
> > >
> > >
> > > > PS I don't think that I have see the problem that you have
> > > reported. I run
> > > > TC 5.5.9 on WinXP with Mysql 4.1.11 and Connector/J 3.1.8,
> > > have never
> > > > noticed that problem, my pools always seem to clean up fine.
> > >
> > > You might not have the same setup. I would suggest to try the
> > > following:
> > >
> > > 1. make sure you define the datasource in
> META-INF/context.xml and you
> > > access the DB using that JNDI datasource.
> > > 2. package your webapp as a war
> > > 3. Do a "netstat" and note how many DB connections are open
> > > 4. deploy your webapp using the ant task or the manager webapp
> > > 5. Access your webapp to use the DB
> > > 6. Do another "netstat" to confirm that there is one more DB
> > > connection (which is now pooled)
> > > 7. undeploy your webapp using the ant task or the manager
> webapp (do
> > > not stop tomcat)
> > > 8. Do one more "netstat" and I would be very surprised if
> the extra
> > > connection was closed :-)
> > >
> > > Another explanation for your finding could be setting
> maxIdle="0" in
> > > the resource definition, but that practically disables pooling.
> > >
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: DBCP connection leak after undeploy
In our company we share several Tomcat servers for all developers, so
that's why we use deploy/undeploy instead of start/stop.
As a workaround for this problem, you can create a
ServletContextListener and close the datasource yourself in
contextDestroyed(). I used refection here to avoid compile time
dependency on Tomcat DBCP.
try
{
Context initCtx = new InitialContext();
ds = (DataSource) initCtx.lookup("java:comp/env/jdbc/YourDSName");
if ("org.apache.tomcat.dbcp.dbcp.BasicDataSource".equals(
ds.getClass().getName()))
{
Method closeMethod = ds.getClass().getMethod("close");
closeMethod.invoke(ds);
}
catch (Exception e)
{
yourLog.error("Failed to close DBCP DataSource.", e);
}
The above code would actually not work because JNDI is destroyed by
the time contextDestroyed() is called (see
http://issues.apache.org/bugzilla/show_bug.cgi?id=37264) so you could
do the lookup and cache the datasource object in contextInitialized().
On 10/28/05, Steve Kirk <[EMAIL PROTECTED]> wrote:
> Yes, confirmed, I get the same problem. (I used the undeploy command from
> within the NetBeans runtime window, and also checked using the undeploy link
> in the browser from /manager/html/). Conns are cleaned up OK if you
> start/stop TC, but not if you undeploy the app with TC still running, as you
> said.
>
> Having said that, does anyone undeploy apps like this on production servers?
> I wouldn't think so, but then again I suppose it might affect ISP type
> users.
>
> PS I have these config values:
> maxActive="10"
> maxIdle="5"
>
> > -Original Message-
> > From: Bogdan Calmac [mailto:[EMAIL PROTECTED]
> > Sent: Thursday 27 October 2005 19:27
> > To: Tomcat Users List
> > Subject: Re: DBCP connection leak after undeploy
> >
> >
> > > PS I don't think that I have see the problem that you have
> > reported. I run
> > > TC 5.5.9 on WinXP with Mysql 4.1.11 and Connector/J 3.1.8,
> > have never
> > > noticed that problem, my pools always seem to clean up fine.
> >
> > You might not have the same setup. I would suggest to try the
> > following:
> >
> > 1. make sure you define the datasource in META-INF/context.xml and you
> > access the DB using that JNDI datasource.
> > 2. package your webapp as a war
> > 3. Do a "netstat" and note how many DB connections are open
> > 4. deploy your webapp using the ant task or the manager webapp
> > 5. Access your webapp to use the DB
> > 6. Do another "netstat" to confirm that there is one more DB
> > connection (which is now pooled)
> > 7. undeploy your webapp using the ant task or the manager webapp (do
> > not stop tomcat)
> > 8. Do one more "netstat" and I would be very surprised if the extra
> > connection was closed :-)
> >
> > Another explanation for your finding could be setting maxIdle="0" in
> > the resource definition, but that practically disables pooling.
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: DBCP connection leak after undeploy
Yes, confirmed, I get the same problem. (I used the undeploy command from within the NetBeans runtime window, and also checked using the undeploy link in the browser from /manager/html/). Conns are cleaned up OK if you start/stop TC, but not if you undeploy the app with TC still running, as you said. Having said that, does anyone undeploy apps like this on production servers? I wouldn't think so, but then again I suppose it might affect ISP type users. PS I have these config values: maxActive="10" maxIdle="5" > -Original Message- > From: Bogdan Calmac [mailto:[EMAIL PROTECTED] > Sent: Thursday 27 October 2005 19:27 > To: Tomcat Users List > Subject: Re: DBCP connection leak after undeploy > > > > PS I don't think that I have see the problem that you have > reported. I run > > TC 5.5.9 on WinXP with Mysql 4.1.11 and Connector/J 3.1.8, > have never > > noticed that problem, my pools always seem to clean up fine. > > You might not have the same setup. I would suggest to try the > following: > > 1. make sure you define the datasource in META-INF/context.xml and you > access the DB using that JNDI datasource. > 2. package your webapp as a war > 3. Do a "netstat" and note how many DB connections are open > 4. deploy your webapp using the ant task or the manager webapp > 5. Access your webapp to use the DB > 6. Do another "netstat" to confirm that there is one more DB > connection (which is now pooled) > 7. undeploy your webapp using the ant task or the manager webapp (do > not stop tomcat) > 8. Do one more "netstat" and I would be very surprised if the extra > connection was closed :-) > > Another explanation for your finding could be setting maxIdle="0" in > the resource definition, but that practically disables pooling. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DBCP connection leak after undeploy
> PS I don't think that I have see the problem that you have reported. I run > TC 5.5.9 on WinXP with Mysql 4.1.11 and Connector/J 3.1.8, have never > noticed that problem, my pools always seem to clean up fine. You might not have the same setup. I would suggest to try the following: 1. make sure you define the datasource in META-INF/context.xml and you access the DB using that JNDI datasource. 2. package your webapp as a war 3. Do a "netstat" and note how many DB connections are open 4. deploy your webapp using the ant task or the manager webapp 5. Access your webapp to use the DB 6. Do another "netstat" to confirm that there is one more DB connection (which is now pooled) 7. undeploy your webapp using the ant task or the manager webapp (do not stop tomcat) 8. Do one more "netstat" and I would be very surprised if the extra connection was closed :-) Another explanation for your finding could be setting maxIdle="0" in the resource definition, but that practically disables pooling. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: DBCP connection leak after undeploy
Interesting, thanks for mailing to the list. Have you considered whether managing the DBCP resource yourself might help? In other words you don't have to use the TC container-managed method of declaring DBCP resources if you don't want to. If you wrote a ServletContextListener to create and close the pool and make it available to your webapp, you would have more control over these issues (or to put it another way, you could choose to write the "glueing integration code" yourself). I have this on my "to do" list, because of other issues around using container managed resources. Have not done it yet but I have some quick and dirty code that does it, which I need to combine/adapt. PS I don't think that I have see the problem that you have reported. I run TC 5.5.9 on WinXP with Mysql 4.1.11 and Connector/J 3.1.8, have never noticed that problem, my pools always seem to clean up fine. > -Original Message- > From: Bogdan Calmac [mailto:[EMAIL PROTECTED] > Sent: Thursday 27 October 2005 16:49 > To: Tomcat Users List > Subject: Re: DBCP connection leak after undeploy > > > This problem is caused by Tomcat not cleaning up the JDBC resources > defined in context.xml. When a context is stopped the DBCP resource is > not notified and the pooled connections are leaked. I've submitted a > bug along with a fix > (http://issues.apache.org/bugzilla/show_bug.cgi?id=37262) but it was > rejected on the grounds that DBCP is an some external library and > tomcat should not contain any glueing integration code. > > I'm not verry happy about it, because connection leaks seem like a > pretty serious issue to me. But hey, why do I complain, I din not pay > a dime for Tomcat, right? > > On 10/26/05, Bogdan Calmac <[EMAIL PROTECTED]> wrote: > > When tomcat is stopped the connection is closed. I'll > probably submit > > the example to bugzilla. Can somebody familiar with the code suggest > > which catalina object keeps a reference of the datasource (beside > > being registered in JNDI)? > > > > On 10/26/05, Steve Kirk <[EMAIL PROTECTED]> wrote: > > > > > > Your code and config below look fine to me, conns seem to > be returned OK to > > > pool as you say. Sounds to me like the pool itself > leaves the database with > > > hanging conns in the pool when it goes down. > > > > > > When you say "If I deploy/undeploy several times" do you > stop and restart TC > > > between undeploy and redeploy? If so, might be worth > trying to see whether > > > the problem still happens if you stop and restart TC > cleanly rather than > > > redeploying the webapp while TC is running? Might help > narrow down the > > > cause slightly. Might be worth reporting to bugzilla? > > > > > > > -Original Message- > > > > From: Bogdan Calmac [mailto:[EMAIL PROTECTED] > > > > Sent: Wednesday 26 October 2005 02:18 > > > > To: users@tomcat.apache.org > > > > Subject: DBCP connection leak after undeploy > > > > > > > > > > > > I've written a simple web application consisting of a > servlet which > > > > does a select from a table and displays the result. It is then > > > > packaged as a war and deployed using the tomcat ant task. After > > > > executing the servlet, it is undeployed using the ant > task again. > > > > stdout confirms that the webapp is deployed and > undeployed without > > > > errors. The problem is that the connection to the DB is > left open even > > > > after undeploy. > > > > > > > > Software used: > > > > - tomcat 5.5.9 on Windows > > > > - DBCP connection pool > > > > - MSSQL server > > > > > > > > The datasource is defined in META-INF/context.xml with: > > > > > > > >> > > type="javax.sql.DataSource" > > > >maxActive="5" maxIdle="2" maxWait="1" > > > >username="sa" password="sa" > > > > > driverClassName="net.sourceforge.jtds.jdbc.Driver" > > > >url="jdbc:jtds:sqlserver://localhost/pubs"/> > > > > > > > > and then referenced in WEB-INF/web.xml with: > > > > > > > > > > > > DB Connection > > > > jdbc/default > > > > javax.sql.DataSource > > > > Container > > > > > > >
Re: DBCP connection leak after undeploy
This problem is caused by Tomcat not cleaning up the JDBC resources
defined in context.xml. When a context is stopped the DBCP resource is
not notified and the pooled connections are leaked. I've submitted a
bug along with a fix
(http://issues.apache.org/bugzilla/show_bug.cgi?id=37262) but it was
rejected on the grounds that DBCP is an some external library and
tomcat should not contain any glueing integration code.
I'm not verry happy about it, because connection leaks seem like a
pretty serious issue to me. But hey, why do I complain, I din not pay
a dime for Tomcat, right?
On 10/26/05, Bogdan Calmac <[EMAIL PROTECTED]> wrote:
> When tomcat is stopped the connection is closed. I'll probably submit
> the example to bugzilla. Can somebody familiar with the code suggest
> which catalina object keeps a reference of the datasource (beside
> being registered in JNDI)?
>
> On 10/26/05, Steve Kirk <[EMAIL PROTECTED]> wrote:
> >
> > Your code and config below look fine to me, conns seem to be returned OK to
> > pool as you say. Sounds to me like the pool itself leaves the database with
> > hanging conns in the pool when it goes down.
> >
> > When you say "If I deploy/undeploy several times" do you stop and restart TC
> > between undeploy and redeploy? If so, might be worth trying to see whether
> > the problem still happens if you stop and restart TC cleanly rather than
> > redeploying the webapp while TC is running? Might help narrow down the
> > cause slightly. Might be worth reporting to bugzilla?
> >
> > > -Original Message-
> > > From: Bogdan Calmac [mailto:[EMAIL PROTECTED]
> > > Sent: Wednesday 26 October 2005 02:18
> > > To: users@tomcat.apache.org
> > > Subject: DBCP connection leak after undeploy
> > >
> > >
> > > I've written a simple web application consisting of a servlet which
> > > does a select from a table and displays the result. It is then
> > > packaged as a war and deployed using the tomcat ant task. After
> > > executing the servlet, it is undeployed using the ant task again.
> > > stdout confirms that the webapp is deployed and undeployed without
> > > errors. The problem is that the connection to the DB is left open even
> > > after undeploy.
> > >
> > > Software used:
> > > - tomcat 5.5.9 on Windows
> > > - DBCP connection pool
> > > - MSSQL server
> > >
> > > The datasource is defined in META-INF/context.xml with:
> > >
> > >> > type="javax.sql.DataSource"
> > >maxActive="5" maxIdle="2" maxWait="1"
> > >username="sa" password="sa"
> > >driverClassName="net.sourceforge.jtds.jdbc.Driver"
> > >url="jdbc:jtds:sqlserver://localhost/pubs"/>
> > >
> > > and then referenced in WEB-INF/web.xml with:
> > >
> > >
> > > DB Connection
> > > jdbc/default
> > > javax.sql.DataSource
> > > Container
> > >
> > >
> > > The code accessing the database is:
> > >
> > > private long getTitlesCount() {
> > > Connection conn = null;
> > > Statement stmt = null;
> > > ResultSet rs = null;
> > > try {
> > > InitialContext cxt = new InitialContext();
> > > DataSource ds = (DataSource) cxt.lookup(
> > > "java:/comp/env/jdbc/default" );
> > > conn = ds.getConnection();
> > > stmt = conn.createStatement();
> > > rs = stmt.executeQuery("select count(*) from titles");
> > > if (rs.next())
> > > return rs.getLong(1);
> > >
> > > }
> > > catch(Exception e) {
> > > System.out.println("Failed to retrive title count
> > > from the DB.");
> > > e.printStackTrace();
> > > }
> > > finally {
> > > if (rs != null) try { rs.close(); } catch (Exception e) {}
> > > if (stmt != null) try { stmt.close(); } catch (Exception e) {}
> > > if (conn != null) try { conn.close(); } catch (Exception e) {}
> > > }
> > > return -1;
> > > }
> > >
> > >
> > > If I deploy/undeploy several times, the number of leaked connections
> > > is incremented with 1 each time.
> > >
> > > If I execute the servlet several times, the number of connections
> > > remains constant, which confirms that the servlet releases the
> > > connection properly.
> > >
> > > My guess is that the datasource is not tied to the webapp and it is
> > > not notified/released when the webapp is undeployed.
> > >
> > > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: DBCP connection leak after undeploy
When tomcat is stopped the connection is closed. I'll probably submit
the example to bugzilla. Can somebody familiar with the code suggest
which catalina object keeps a reference of the datasource (beside
being registered in JNDI)?
On 10/26/05, Steve Kirk <[EMAIL PROTECTED]> wrote:
>
> Your code and config below look fine to me, conns seem to be returned OK to
> pool as you say. Sounds to me like the pool itself leaves the database with
> hanging conns in the pool when it goes down.
>
> When you say "If I deploy/undeploy several times" do you stop and restart TC
> between undeploy and redeploy? If so, might be worth trying to see whether
> the problem still happens if you stop and restart TC cleanly rather than
> redeploying the webapp while TC is running? Might help narrow down the
> cause slightly. Might be worth reporting to bugzilla?
>
> > -Original Message-
> > From: Bogdan Calmac [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday 26 October 2005 02:18
> > To: users@tomcat.apache.org
> > Subject: DBCP connection leak after undeploy
> >
> >
> > I've written a simple web application consisting of a servlet which
> > does a select from a table and displays the result. It is then
> > packaged as a war and deployed using the tomcat ant task. After
> > executing the servlet, it is undeployed using the ant task again.
> > stdout confirms that the webapp is deployed and undeployed without
> > errors. The problem is that the connection to the DB is left open even
> > after undeploy.
> >
> > Software used:
> > - tomcat 5.5.9 on Windows
> > - DBCP connection pool
> > - MSSQL server
> >
> > The datasource is defined in META-INF/context.xml with:
> >
> >> type="javax.sql.DataSource"
> >maxActive="5" maxIdle="2" maxWait="1"
> >username="sa" password="sa"
> >driverClassName="net.sourceforge.jtds.jdbc.Driver"
> >url="jdbc:jtds:sqlserver://localhost/pubs"/>
> >
> > and then referenced in WEB-INF/web.xml with:
> >
> >
> > DB Connection
> > jdbc/default
> > javax.sql.DataSource
> > Container
> >
> >
> > The code accessing the database is:
> >
> > private long getTitlesCount() {
> > Connection conn = null;
> > Statement stmt = null;
> > ResultSet rs = null;
> > try {
> > InitialContext cxt = new InitialContext();
> > DataSource ds = (DataSource) cxt.lookup(
> > "java:/comp/env/jdbc/default" );
> > conn = ds.getConnection();
> > stmt = conn.createStatement();
> > rs = stmt.executeQuery("select count(*) from titles");
> > if (rs.next())
> > return rs.getLong(1);
> >
> > }
> > catch(Exception e) {
> > System.out.println("Failed to retrive title count
> > from the DB.");
> > e.printStackTrace();
> > }
> > finally {
> > if (rs != null) try { rs.close(); } catch (Exception e) {}
> > if (stmt != null) try { stmt.close(); } catch (Exception e) {}
> > if (conn != null) try { conn.close(); } catch (Exception e) {}
> > }
> > return -1;
> > }
> >
> >
> > If I deploy/undeploy several times, the number of leaked connections
> > is incremented with 1 each time.
> >
> > If I execute the servlet several times, the number of connections
> > remains constant, which confirms that the servlet releases the
> > connection properly.
> >
> > My guess is that the datasource is not tied to the webapp and it is
> > not notified/released when the webapp is undeployed.
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: DBCP connection leak after undeploy
Your code and config below look fine to me, conns seem to be returned OK to
pool as you say. Sounds to me like the pool itself leaves the database with
hanging conns in the pool when it goes down.
When you say "If I deploy/undeploy several times" do you stop and restart TC
between undeploy and redeploy? If so, might be worth trying to see whether
the problem still happens if you stop and restart TC cleanly rather than
redeploying the webapp while TC is running? Might help narrow down the
cause slightly. Might be worth reporting to bugzilla?
> -Original Message-
> From: Bogdan Calmac [mailto:[EMAIL PROTECTED]
> Sent: Wednesday 26 October 2005 02:18
> To: users@tomcat.apache.org
> Subject: DBCP connection leak after undeploy
>
>
> I've written a simple web application consisting of a servlet which
> does a select from a table and displays the result. It is then
> packaged as a war and deployed using the tomcat ant task. After
> executing the servlet, it is undeployed using the ant task again.
> stdout confirms that the webapp is deployed and undeployed without
> errors. The problem is that the connection to the DB is left open even
> after undeploy.
>
> Software used:
> - tomcat 5.5.9 on Windows
> - DBCP connection pool
> - MSSQL server
>
> The datasource is defined in META-INF/context.xml with:
>
>type="javax.sql.DataSource"
>maxActive="5" maxIdle="2" maxWait="1"
>username="sa" password="sa"
>driverClassName="net.sourceforge.jtds.jdbc.Driver"
>url="jdbc:jtds:sqlserver://localhost/pubs"/>
>
> and then referenced in WEB-INF/web.xml with:
>
>
> DB Connection
> jdbc/default
> javax.sql.DataSource
> Container
>
>
> The code accessing the database is:
>
> private long getTitlesCount() {
> Connection conn = null;
> Statement stmt = null;
> ResultSet rs = null;
> try {
> InitialContext cxt = new InitialContext();
> DataSource ds = (DataSource) cxt.lookup(
> "java:/comp/env/jdbc/default" );
> conn = ds.getConnection();
> stmt = conn.createStatement();
> rs = stmt.executeQuery("select count(*) from titles");
> if (rs.next())
> return rs.getLong(1);
>
> }
> catch(Exception e) {
> System.out.println("Failed to retrive title count
> from the DB.");
> e.printStackTrace();
> }
> finally {
> if (rs != null) try { rs.close(); } catch (Exception e) {}
> if (stmt != null) try { stmt.close(); } catch (Exception e) {}
> if (conn != null) try { conn.close(); } catch (Exception e) {}
> }
> return -1;
> }
>
>
> If I deploy/undeploy several times, the number of leaked connections
> is incremented with 1 each time.
>
> If I execute the servlet several times, the number of connections
> remains constant, which confirms that the servlet releases the
> connection properly.
>
> My guess is that the datasource is not tied to the webapp and it is
> not notified/released when the webapp is undeployed.
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DBCP connection leak after undeploy
I've written a simple web application consisting of a servlet which
does a select from a table and displays the result. It is then
packaged as a war and deployed using the tomcat ant task. After
executing the servlet, it is undeployed using the ant task again.
stdout confirms that the webapp is deployed and undeployed without
errors. The problem is that the connection to the DB is left open even
after undeploy.
Software used:
- tomcat 5.5.9 on Windows
- DBCP connection pool
- MSSQL server
The datasource is defined in META-INF/context.xml with:
and then referenced in WEB-INF/web.xml with:
DB Connection
jdbc/default
javax.sql.DataSource
Container
The code accessing the database is:
private long getTitlesCount() {
Connection conn = null;
Statement stmt = null;
ResultSet rs = null;
try {
InitialContext cxt = new InitialContext();
DataSource ds = (DataSource) cxt.lookup(
"java:/comp/env/jdbc/default" );
conn = ds.getConnection();
stmt = conn.createStatement();
rs = stmt.executeQuery("select count(*) from titles");
if (rs.next())
return rs.getLong(1);
}
catch(Exception e) {
System.out.println("Failed to retrive title count from the DB.");
e.printStackTrace();
}
finally {
if (rs != null) try { rs.close(); } catch (Exception e) {}
if (stmt != null) try { stmt.close(); } catch (Exception e) {}
if (conn != null) try { conn.close(); } catch (Exception e) {}
}
return -1;
}
If I deploy/undeploy several times, the number of leaked connections
is incremented with 1 each time.
If I execute the servlet several times, the number of connections
remains constant, which confirms that the servlet releases the
connection properly.
My guess is that the datasource is not tied to the webapp and it is
not notified/released when the webapp is undeployed.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
