Re: [EXTERNAL]Re: DBCP issuing more sessions than maxActive sessions in Oracle

[Romero , René]

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: user-unsubscr...@commons.apache.org > For additional 
commands, e-mail: user-h...@commons.apache.org > > This message was received 
from outside of the Omnitracs network > 
- To 
unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional 
commands, e-mail: user-h...@commons.apache.org

Re: JCS : element expires sooner than configured

[Thomas Vandahl]

Ouch, that hurt. I'm sorry, this is a problem with ElementAttributes.clone() 
not updating createTime. I fixed it in trunk. Could you try if it works for you?

Bye, Thomas 

-- tv

> Am 23.01.2017 um 10:48 schrieb Sahib Bin Mahboob Ron :
> 
> Hi,
> 
> I am trying to configure a JCS using the following configuration:
> 
> # DEFAULT CACHE REGION
> 
> jcs.default=
> jcs.default.cacheattributes=
>org.apache.commons.jcs.engine.CompositeCacheAttributes
> jcs.default.cacheattributes.MaxObjects=1000
> jcs.default.cacheattributes.MemoryCacheName=
>org.apache.commons.jcs.engine.memory.lru.LRUMemoryCache
> 
> jcs.default.elementattributes=org.apache.commons.jcs.engine.ElementAttributes
> jcs.default.elementattributes.IsEternal=false
> jcs.default.elementattributes.MaxLife=300
> jcs.default.elementattributes.IsSpool=false
> 
> 
> While it is expected to expire the item in 300 seconds as per MaxLife
> configuration, it does not work properly in following steps:
> 
> 1. Putting a key "aKey" for the first time in cache: It works perfectly.
> 2. "aKey" expires after 300 seconds.
> 3. Put "aKey" again on the cache.
> 4. It expires immediately.
> 
> Am I missing any configuration or this is the way it should behave?
> 
> - Sahib


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [EXTERNAL]Re: DBCP issuing more sessions than maxActive sessions in Oracle

[Phil Steitz]

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:url="${dw.db.url}" p:username="${dw.db.username}"
>> 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: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
>
> This message was received from outside of the Omnitracs network
>



-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org