cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: Pool contracts (Was Re: [Fwd: [C2] [Bug] ComponentNotAccessibleException])
Date Mon, 26 Feb 2001 14:35:53 GMT
Sorry, I sent this to the wrong list.

Berin Loritsch wrote:
> 
> 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
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org

Mime
View raw message