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