RE: [Excalibur] DefaultPool: Could not create enough components t o service your request

[to...@the-ecorp.com]

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

Re: [Excalibur] DefaultPool: Could not create enough components to service your request

[Berin Loritsch <bl...@apache.org>]

tom.klaasen@the-ecorp.com wrote:
> 
> 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.

No.  HardResourceLimitingPool overrides the newPoolable() method that throws
an exception if the resource is not allowed to be created.

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

I did an initial test with Cocoon 2 on my machine with 200 simultaneous users,
and I couldn't break it.  Of course, I don't have an SMP machine available to
me yet--but it's hard to argue with those results.

Check my post on Cocoon-dev.

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