commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <ma...@apache.org>
Subject Re: [GenericObjectPool] problem with numActive counter
Date Fri, 15 Jan 2010 12:11:17 GMT
On 15/01/2010 12:07, Daniele Bonetto wrote:
> I've already the latest version... :(((
> 
> Other suggestions??

Could be a pool bug. Could you provide some more detail about what your
obejct factory is doing when the network is down. Does it create
objects? Does it validate them?

Mark

> 
> Daniele
> 
> 
> 
> 
> Il 15/01/2010 12.23, Mark Thomas ha scritto:
>> On 15/01/2010 10:59, Daniele Bonetto wrote:
>>   
>>> yes, but if i don't invalidate the object i continue to have the problem
>>>
>>> Timeout waiting for idle object
>>>
>>> that blocks my pool as u can see in the following examples... :(
>>>      
>> Which version of pool are you using? If not 1.5.4, try upgrading as
>> there were a couple of bugs in the earlier 1.5.x releases that could
>> cause this.
>>
>> Mark
>>
>>   
>>> */Example 1: without invalidateObject/*
>>>
>>> MaxActive = 2
>>> NumActive = 0
>>>
>>> -->  Network is ok.
>>> Borrow obj1 -->  ok [numActive 1]
>>> Borrow obj2 -->  ok [numActive 2]
>>> Borrow obj3 -->  nok, maxActive reached [numActive 2]
>>> Return obj1 [numActive 1]
>>> Return obj2 [numActive 0]
>>> Borrow obj3 -->  ok [numActive 1]
>>> Return obj3 [numActive 0]
>>>
>>> -->  Network turns nok.
>>> Borrow obj1 -->  nok, cannot create an activated object [numActive 0]
>>> Borrow obj2 -->  nok, cannot create an activated object [numActive 0]
>>> Borrow obj3 -->  nok, timeout waiting for idle object [numActive 0]
>>>
>>> -->  Network turns ok.
>>> Borrow obj1 -->  nok, timeout waiting for idle object [numActive 0]
>>> Borrow obj2 -->  nok, timeout waiting for idle object [numActive 0]
>>> Borrow obj3 -->  nok, timeout waiting for idle object [numActive 0]
>>>
>>> and so on... It persists forever, locking my pool...
>>>
>>>
>>>
>>> */Example 2: with invalidateObject/*
>>>
>>> MaxActive = 2
>>> NumActive = 0
>>>
>>> -->  Network is ok.
>>> Borrow obj1 -->  ok [numActive 1]
>>> Borrow obj2 -->  ok [numActive 2]
>>> Borrow obj3 -->  nok, maxActive reached [numActive 2]
>>> Return obj1 [numActive 1]
>>> Return obj2 [numActive 0]
>>> Borrow obj3 -->  ok [numActive 1]
>>> Return obj3 [numActive 0]
>>>
>>> -->  Network turns nok.
>>> Borrow obj1 -->  nok, cannot create an activated object [numActive 0]
>>> Invalidate obj1 [numActive -1]
>>> Borrow obj2 -->  nok, cannot create an activated object [numActive -1]
>>> Invalidate obj2 [numActive -2]
>>> Borrow obj3 -->  nok, cannot create an activated object [numActive -2]
>>> Invalidate obj3 [numActive -3]
>>>
>>> -->  Network turns ok.
>>> Borrow obj1 -->  ok [numActive -2]
>>> Borrow obj2 -->  ok [numActive -1]
>>> Borrow obj3 -->  ok [numActive 0]
>>> Return obj1 [numActive -1]
>>> Return obj2 [numActive -2]
>>> Return obj3 [numActive -3]
>>>
>>> In this case the object are correctly borrowed and the pool works well,
>>> but the numActive counter isn't correct and it make me borrow more than
>>> 2 objects (and it's a big problem cause i have limited connections to
>>> respect).
>>>
>>> Byez!
>>> Daniele Bonetto
>>>
>>>
>>>
>>>
>>>
>>> Il 15/01/2010 11.37, Simone Tripodi ha scritto:
>>>     
>>>> In the example, the catch group catches exceptions that could be
>>>> thrown by the object _use_, I *suppose* whenever you catch a
>>>> java.util.NoSuchElementException you don't need to invalidate the
>>>> object, that's what Mark was pointing.
>>>> let us know, all the best,
>>>> Simo
>>>>
>>>> On Fri, Jan 15, 2010 at 11:26 AM, Daniele Bonetto
>>>> <daniele.bonetto@dnshosting.it>   wrote:
>>>>
>>>>       
>>>>> Ok, if the borrow throws an exceptin the obj was null.
>>>>> But i'm not sure that the invalidate was unnecessary. take a look at
>>>>> this:
>>>>> http://commons.apache.org/pool/apidocs/org/apache/commons/pool/ObjectPool.html
>>>>>
>>>>>
>>>>>
>>>>> Example of use:
>>>>>
>>>>>    Object obj =|null|;
>>>>>
>>>>>    |try|  {
>>>>>       obj = pool.borrowObject();
>>>>>       |//...use the object...|
>>>>>    }|catch|(Exception e) {
>>>>>       |// invalidate the object|
>>>>>       pool.invalidateObject(obj);
>>>>>       |// do not return the object to the pool twice|
>>>>>       obj =|null|;
>>>>>    }|finally|  {
>>>>>       |// make sure the object is returned to the pool|
>>>>>       |if|(|null|  != obj) {
>>>>>           pool.returnObject(obj);
>>>>>      }
>>>>>    }
>>>>>
>>>>>
>>>>> In this example u can see that if the borrow throws an exception u
>>>>> have to
>>>>> invalidate the object from pool.
>>>>>
>>>>> So. What happends to the object that i tried to borrow?
>>>>>
>>>>> I have maxActive = 2 and without invalidate if i try more than 2
>>>>> times the
>>>>> pool returns always:
>>>>>
>>>>> java.util.NoSuchElementException: Timeout waiting for idle object
>>>>>
>>>>>
>>>>> I think that without the invalidate the object remains in idle and it
>>>>> locks
>>>>> my pool... With invalidateObject the pool works correctly, but the
>>>>> counter
>>>>> wasn't correct.
>>>>>
>>>>> Thanks guys for your replies.
>>>>>
>>>>> Byez!
>>>>> Daniele Bonetto
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Il 15/01/2010 11.08, Mark Thomas ha scritto:
>>>>>
>>>>>         
>>>>>> On 15/01/2010 10:03, Simone Tripodi wrote:
>>>>>>
>>>>>>
>>>>>>           
>>>>>>> Ciao Daniele ;)
>>>>>>> First, I suggest you to start the subject line with [componentname],
>>>>>>> i.e. [POOL] if you're referring commons-pool, otherwise people
>>>>>>> risk to
>>>>>>> get confused and not able to reply.
>>>>>>>
>>>>>>> I don't know the Pool so deeply and maybe I didn't understand
the
>>>>>>> problem, but reading your code I'm worried 'invalidateObject()'
>>>>>>> always
>>>>>>> takes 'null' as argument... take a look at this with the
>>>>>>> logger/debugger.
>>>>>>>
>>>>>>>
>>>>>>>              
>>>>>> Yep. That's the problem. That call is almost certainly
>>>>>> unnecessary. If
>>>>>> want to keep it, wrap it in a<code>if  (obj != null)</code>
    test.
>>>>>>
>>>>>> Mark
>>>>>>
>>>>>>
>>>>>>
>>>>>>           
>>>>>>> All the best,
>>>>>>> Simo
>>>>>>>
>>>>>>> On Fri, Jan 15, 2010 at 10:53 AM, Daniele Bonetto
>>>>>>> <daniele.bonetto@dnshosting.it>     wrote:
>>>>>>>
>>>>>>>
>>>>>>>             
>>>>>>>> Hello everyone!
>>>>>>>>
>>>>>>>> I notice a problem using GenericObjectPool.
>>>>>>>>
>>>>>>>> My code is like this:
>>>>>>>>
>>>>>>>>          Object obj = null;
>>>>>>>>          try
>>>>>>>>          {
>>>>>>>>                  obj = this.borrowObject();
>>>>>>>>          }
>>>>>>>>          catch(NoSuchElementException ex)
>>>>>>>>          {
>>>>>>>>              log.error("no such element exception", ex);
>>>>>>>>              this.invalidateObject(obj);
>>>>>>>>              throw new NicProviderPoolException("no such
element
>>>>>>>> exception",
>>>>>>>> ex);
>>>>>>>>          }
>>>>>>>>          catch(Exception ex)
>>>>>>>>          {
>>>>>>>>              log.error("exception", ex);
>>>>>>>>              this.invalidateObject(obj);
>>>>>>>>              throw new Exception("exception", ex);
>>>>>>>>          }
>>>>>>>>          return (NicProvider)obj;
>>>>>>>>
>>>>>>>> When the borrowObject throws an exception and i invalidate
the
>>>>>>>> borrowedObject the numActive counter was decreased by 1.
The
>>>>>>>> problem is
>>>>>>>> that
>>>>>>>> the counter will not be increased in case of exception...
So, my
>>>>>>>> numActive
>>>>>>>> counter will be -1 and isn't correct.
>>>>>>>>
>>>>>>>> Someone has noticed this problem too?
>>>>>>>>
>>>>>>>> Thanks in advance,
>>>>>>>> Byez!
>>>>>>>>
>>>>>>>> Daniele Bonetto
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>
>>>>>>>> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail: user-help@commons.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>                
>>>>>>>
>>>>>>>
>>>>>>>              
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: user-help@commons.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>            
>>>>>
>>>>>          
>>>>
>>>>
>>>>        
>>>      
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
>> For additional commands, e-mail: user-help@commons.apache.org
>>
>>
>>
>>
>>    
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
> 




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


Mime
View raw message