I see, thanks a lot for shedding light on that misconfiguration Phil. Fit mind in fit body.
From: Phil Steitz Sent: Wednesday, January 25, 8:33 AM Subject: Re: [EXTERNAL]Re: DBCP issuing more sessions than maxActive sessions in Oracle To: Commons Users List On 1/24/17 4:55 PM, Romero, René wrote: > We're running commons-dbcp-1.4 and commons-pool-1.6. To me, it sounds like we're being impacted by this bug: > > https://issues.apache.org/jira/browse/DBCP-379 > > [DBCP-379] number of connections created has crossed more ... > issues.apache.org > I found that when the minIdle is configured then during loads, common pool creates more number of connections it will be greater than maxActive. > > Is it transparent application-wise to jump from these versions to the latests? Or what upgrading path do you suggest we take? > > > Thanks again. > > > > Rene Romero Benavides > Administrador de Bases de Datos para Command Center > +52(55) 11020460 Ext. 6432 | Office > > +52 1 5545664012 | Mobile > > www.omnitracs.com/mx > > Register today! www.omnitracs.com/outlook > > > ________________________________ > From: Phil Steitz > Sent: Tuesday, January 24, 2017 3:43:29 PM > To: Commons Users List > Subject: [EXTERNAL]Re: DBCP issuing more sessions than maxActive sessions in Oracle > > What versions of dbcp and pool are you running? > > Looks like 1.x from the package names. The first thing to look at > is the changelogs[1] for releases since the pool and dbcp versions > that you are running. > > Phil > > [1] for dbcp this is > https://commons.apache.org/proper/commons-dbcp/changes-report.html > There is a similar page on the pool site. > > On 1/24/17 3:02 PM, Romero, René wrote: >> Hello guys. >> >> Under what circumstances could we get more than MaxActive sessions in the database if DBCP is our only means of access to it? >> >> This is our current configuration and it's surpassing 160 Oracle sessions at times when it shouldn't go beyond 32 (our current value for MaxActive). >> >> >> DB = Oracle 11g >> >> Data access via spring famework. >> >> >> Thanks in advance. >> >> >> > p:password="${dw.db.password}" p:driverClassName="${dw.db.driverClassName}" init-method="createDataSource" destroy-method="close"> >> >> >> >> >> >> >> >> >> >> >> dw.db.url=jdbc:oracle:thin:someDB/somePass@someHost:1522:SomeInstance >> dw.db.username=someUser >> dw.db.password=somePass >> dw.db.driverClassName=oracle.jdbc.OracleDriver >> dw.db.allowed.operations=select >> dw.db.schema=1|COMMON_APP_VIEWS_01, 81|COMMON_APP_VIEWS_81 >> dw.db.maxRows=500 >> dw.db.type=ORACLE >> dw.db.validation.query=select 1 from dual >> dw.db.initial.connection.size=4 >> dw.db.max.connection.size=32 >> dw.db.minIdle.connections=4 >> dw.db.maxIdle.connections=4 The settings above will create a lot of connection churn and may be what is causing you to hit an old pool or dbcp bug. When you set minIdle = maxIdle, you are telling the pool that it needs to try to keep *exactly* that number (in your case 4) idle connections at all times. The maxIdle setting means that when there are already 4 idle connections and a 5th is returned, it is destroyed. If the idle count subsequently drops below that, since you have the evictor enabled, it will try to ensureMinIdle when it runs, creating new ones. In general, it is better to have maxIdle >> minIdle. This applies to dbcp2 as well. Phil >> >> >> What other info would you need? >> >> >> Rene Romero Benavides >> Administrador de Bases de Datos para Command Center >> +52(55) 11020460 Ext. 6432 | Office >> >> +52 1 5545664012 | Mobile >> >> www.omnitracs.com/mx> >> >> Register today! www.omnitracs.com/outlook> >> >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > This message was received from outside of the Omnitracs network > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
