cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Pool contracts (Was Re: [Fwd: [C2] [Bug] ComponentNotAccessibleException])
Date Mon, 26 Feb 2001 14:24:16 GMT
I have a feeling that we are dealing with a Race Condition on the AbstractPool.

I think we should make all Pools ThreadSafe.  This contract will make things
alot easier for people who are implementing pools in concurrent execution
environments (i.e. multithreaded).  In cocoon, I will explicitly synchronize
the get() and set() methods--but this is a temporary stop-gap until we make
the Pool implementation thread-safe.

I do think there is room for multiple different types of pools:

* Hard resource limiting (Absolutely no more than X components)
* Soft resource limiting (May have more than X, but extras are destroyed when returned)
* No resource limiting (As extras are needed, they are created and maintained)

For Web environments where you need to have explicit controls over
resource usage, Hard resource limiting is a *very* useful tool.  It
means that we can guarantee that memory usage won't grow out of control
during usage peaks.  Hard resource limiting also requires method of
waiting for a resource to be returned to the pool.

For environments where the usage does not routinely spike extra high
soft resource limiting has added performance boosts because the resource
is returned right away.  It also manages the resource alocation because
when the resource is returned to the pool and the pool already has
the max resources, then the extra ones are destroyed.

For very stable environments that have a steady resource usage, the
No resource limiting pool will have the best performance because the
pool will be filled with the number of resources already necessary.
It won't be practical for environments with usage spikes because the pool
will be sized for the highest spike--which most of the time is wasted
space.

Peter Donald wrote:
> 
> Oh and also add the import
> 
> import org.apache.avalon.util.log.AvalonLogFormatter;
> 
> ;)
> 
> At 05:49  26/2/01 +1100, Peter Donald wrote:
> >Hi,
> >
> >It is a bit hard to track this down directly although there was a bugfix a
> >while back regarding a similar exception. SO could you change
> >CocoonServlet.java about Line 214 from:
> >
> >            this.log = LogKit.createLogger(cocoonCategory, new LogTarget[] {
> >                       new FileOutputLogTarget(path),
> >                       new ServletLogTarget(context, Priority.ERROR)
> >                });
> >
> >to:
> >        final AvalonLogFormatter formatter = new AvalonLogFormatter();
> >        final LogTarget fileLogTarget = new FileOutputLogTarget(path);
> >        final LogTarget servletLogTarget =
> >                  new ServletLogTarget(context, Priority.ERROR);
> >
> >        //set up some formatter - as long as it includes throwable
> >        formatter.setFormat( "%{time} [%7.7{priority}] <<%{category}>>
" +
> >                             "(%{context}): %{message}\\n%{throwable}" );
> >
> >        fileLogTarget.setFormatter( formatter );
> >        servletLogTarget.setFormatter( formatter );
> >
> >        this.log = LogKit.createLogger(cocoonCategory, new LogTarget[] {
> >                       fileLogTarget,
> >                       servletLogTarget
> >                });
> >
> >The above will just print out exactly where the error is by recursing the
> >Cascading Exceptions and printing out the whole exception hierarchy.
> >
> >And could you also tell me the date of Avalon this was compiled against?
> >Given that I think it should be easier to fix the error.
> >
> >
> >Cheers,
> >
> >Pete
> >
> >*-----------------------------------------------------*
> >| "Faced with the choice between changing one's mind, |
> >| and proving that there is no need to do so - almost |
> >| everyone gets busy on the proof."                   |
> >|              - John Kenneth Galbraith               |
> >*-----------------------------------------------------*
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
> >
> >
> Cheers,
> 
> Pete
> 
> *------------------------------------------------------*
> | "Computers are useless. They can only give you       |
> |            answers." - Pablo Picasso                 |
> *------------------------------------------------------*
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org

Mime
View raw message