avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From tom.klaa...@the-ecorp.com
Subject RE: [Excalibur] DefaultPool: Could not create enough components t o service your request
Date Thu, 09 Aug 2001 15:17:37 GMT
I think I get this -- but doesn't this break the contract of
HardResourceLimitingPool? You seem to create extra resources when the pool
is out of them. And for eg a JDBCConnection this might not be a good idea.

Anyhow, I'll get the new version and put the load again on them. Should be
done sometime tomorrow.

tomK

-----Original Message-----
From: Berin Loritsch [mailto:bloritsch@apache.org]
Sent: donderdag 9 augustus 2001 15:56
To: Avalon Development
Subject: Re: [Excalibur] DefaultPool: Could not create enough components
to service your request


tom.klaasen@the-ecorp.com wrote:
> 
> Hi,
> 
> The error mentioned in the subject line has been reported several times on
> this list.
> 
> Now, when putting load on Cocoon 2, I got the same error. And I found the
> cause.
> 
> The problem is in this piece of code:
> 
> public Poolable get() throws Exception
> <snip/>
>   try
>      {
>       m_mutex.lock();
>       if( m_ready.size() == 0 )
>         {
>          if( this instanceof Resizable )
>            {
>             m_mutex.unlock();
>             ((Resizable)this).grow( m_controller.grow() );  //**
>             m_mutex.lock();
>             if ( m_ready.size() > 0 )
>                    {
>                     obj = (Poolable) m_ready.remove( 0 );
>                    }
>                 else
>                    {<etc/>


I wanted to attempt a different approach first, so I had AbstractPool
implement two protected methods: internalGrow() and internalShrink().
They both assume that the lock has already been aquired and are used
inside the get() and put() methods respectively.  The public Resizeable
grow() and shrink() methods aquire the lock and call the internalGrow()
and internalShrink() methods.

This makes the code snippet look like this:

<snip/>
  try
     {
      m_mutex.lock();
      if( m_ready.size() == 0 )
        {
         if( this instanceof Resizable )
           {
            this.internalGrow( m_controller.grow() ); //**
            if ( m_ready.size() > 0 )
                   {
                    obj = (Poolable) m_ready.remove( 0 );
                   }
                else
                   {<etc/>

Notice the absence of the m_mutex releasing of the lock.  This should kill
two birds with one stone:  killing the race condition, and increased
performance
through decreased iterations.

I will commit it in a few minutes, I would like you to crosscheck it on your
machine.

---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org


Mime
View raw message