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
|