An update on this issue. Yassir tested with a JAR I built against trunk. What this could mean is that the bug https://issues.apache.org/bugzilla/show_bug.cgi?id=53367 somehow didn't make it into the build of 7.0.28
I will double check it. Filip > -----Original Message----- > From: Filip Hanik (mailing lists) [mailto:devli...@hanik.com] > Sent: Thursday, June 28, 2012 2:42 PM > To: 'Tomcat Users List' > Subject: RE: Tomcat 7.0.28 connection pool issue > > Martin, generally I would run with fairQueue="false" - this is the > default. > The only time I would change to fairQueue="true" is if we see threads > being > starved, and not getting connections. However, this scenario is very > unlikely unless there is extreme concurrency going on. > > Filip > > > -----Original Message----- > > From: Martin Gainty [mailto:mgai...@hotmail.com] > > Sent: Thursday, June 28, 2012 1:38 PM > > To: Tomcat Users List > > Subject: RE: Tomcat 7.0.28 connection pool issue > > > > > > Hi Filip > > > > Is there an algorithm we can use to determine if the op should > configure > > concurrent db connections (fairQueue=false) vs config non-concurrent > db > > connections (fairQueue=true) > > e.g. if 50%+ of database cursors are 'read-only' then concurrent > > connections *should be used* and TC attribute of fairQueue should be > set > > to false > > Thanks! > > Martin > > ______________________________________________ > > Place legal disclaimer here > > > > > From: devli...@hanik.com > > > To: users@tomcat.apache.org > > > Subject: RE: Tomcat 7.0.28 connection pool issue > > > Date: Thu, 28 Jun 2012 11:36:49 -0600 > > > > > > Then the issue you may be running into is that your Tomcat > > configuration > > > supports a higher concurrency level than what your Resin > configuration > > is > > > setup to do. > > > With higher concurrency, there will be a need for more data base > > > connections. If you still want to run with a lower number of > > connections, > > > what you can do is set > > > > > > fairQueue="true" > > > maxWait="time in milliseconds to wait for next available connection" > > > > > > and what this effectively will do, is lower your concurrency. > > Recommended is > > > of course to increase maxActive if the database supports it. > > > > > > Filip > > > > > > > > > > -----Original Message----- > > > > From: Yasser [mailto:yarafa...@gmail.com] > > > > Sent: Thursday, June 28, 2012 11:33 AM > > > > To: Tomcat Users List > > > > Subject: Re: Tomcat 7.0.28 connection pool issue > > > > > > > > That was the issue with Tomcat 7.0.26 and they fixed it in 7.0.28 > > > > > > > > > > > > On Thu, Jun 28, 2012 at 11:54 AM, Filip Hanik (mailing lists) < > > > > devli...@hanik.com> wrote: > > > > > > > > > Could you have run into > > > > > https://issues.apache.org/bugzilla/show_bug.cgi?id=53367 > > > > > > > > > > ? > > > > > > > > > > You could try out > > > > > http://people.apache.org/~fhanik/jdbc-pool/bz53367-jdbc-pool.jar > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Yasser [mailto:yarafa...@gmail.com] > > > > > > Sent: Thursday, June 28, 2012 9:39 AM > > > > > > To: Tomcat Users List > > > > > > Subject: Re: Tomcat 7.0.28 connection pool issue > > > > > > > > > > > > Yes. It does show that maxactive has reached 100. I also use > > splunk > > > > to > > > > > > get > > > > > > the connection status at the oracle side. > > > > > > What I dont understand is that Resin needs just 50 connections > > to > > > > handle > > > > > > the same load. I am in the process of increasing the count to > > 300 > > > > and > > > > > > see > > > > > > if that makes a difference. Oracle has the capacity to handle > > that > > > > many > > > > > > connections. > > > > > > > > > > > > > > > > > > On Thu, Jun 28, 2012 at 11:01 AM, Hedrick, Brooke - 43 < > > > > > > brooke.hedr...@rainhail.com> wrote: > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Yasser [mailto:yarafa...@gmail.com] > > > > > > > > Sent: Thursday, June 28, 2012 9:44 AM > > > > > > > > To: users@tomcat.apache.org > > > > > > > > Subject: Tomcat 7.0.28 connection pool issue > > > > > > > > > > > > > > > ... > > > > > > > > What is the issue? > > > > > > > > When we run a stress test on the same codebase deployed to > > > > Tomcat > > > > > > 7.0.28, > > > > > > > > at about 2hr45min into the test with 530 virtual users > > logged in > > > > (at > > > > > > > peak load), > > > > > > > > I get a lot of connection pool empty errors. The maxactive > > > > attribute > > > > > > > (using > > > > > > > > tomcat connection pool) has been set to 100. > > > > > > > > > > > > > > > > > > > > > > Have you used jconsole to monitor the pool usage? > > > > > > > > > > > > > > -Brooke > > > > > > > > > > > > > > > Other information: > > > > > > > > CAS runs on a different server with a dedicated tomcat > home > > and > > > > > > base. I > > > > > > > > dont see any errors on this box. > > > > > > > > 7.0.26 was found to have a bug in the way connection count > > is > > > > > > determined, > > > > > > > > which got fixed in 7.0.28, hence we switched to the latest > > > > version. > > > > > > > > > > > > > > > > Here is one of the connection pool config from server.xml. > > We do > > > > a > > > > > > > resource > > > > > > > > link to this pool in the context.xml > > > > > > > > > > > > > > > > <Resource name="jdbc/global-wl" auth="Container" > > > > > > > > type="javax.sql.DataSource" username="webconnect" > > > > > > > > password="xxxxxxx" > > > > > > > > driverClassName="oracle.jdbc.driver.OracleDriver" > > > > > > > > > > > > > > > > > > > > > url="jdbc:oracle:thin:@&&dbs.ip&&:&&oracle.db.port&&:&&dts.dbname&& > > > > > > > > " > > > > > > > > > > > > factory="org.apache.tomcat.jdbc.pool.DataSourceFactory" > > > > > > > > maxActive="100" /> > > > > > > > > > > > > > > > > Any help is appreciated. Please let me know if you need > more > > > > > > information > > > > > > > or > > > > > > > > code snippets. > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > Yasser > > > > > > > > > > > > > > ------------------------------------------------------------ > -- > > ---- > > > > --- > > > > > > > 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 > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > - > > > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
