You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Peter Donald <do...@apache.org> on 2001/02/26 07:49:24 UTC

Re: [Fwd: [C2] [Bug] ComponentNotAccessibleException]

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               |
*-----------------------------------------------------*


Re: Pool contracts (Was Re: [Fwd: [C2] [Bug] ComponentNotAccessibleException])

Posted by Paul Russell <pa...@luminas.co.uk>.
* Berin Loritsch (bloritsch@apache.org) wrote :
> 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.

We should probably have an AdaptivePool, too. This would be similar to
the no-limits pool except it would gradually shrink back to a sensible
size. This can be implemented in various ways -- e.g. by killing off 10%
of the pooled components over every 30 minute period, with the net
result that if there is a spike, it should get back to normal relatively
quickly. There are better algorithms out there, but you get the idea.


Paul.

-- 
Paul Russell                                 Email:   paul@luminas.co.uk
Technical Director                             Tel:  +44 (0)20 8553 6622
Luminas Internet Applications                  Fax:  +44 (0)870 28 47489
This is not an official statement or order.    Web:    www.luminas.co.uk

Re: Pool contracts (Was Re: [Fwd: [C2] [Bug] ComponentNotAccessibleException])

Posted by Berin Loritsch <bl...@apache.org>.
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

Pool contracts (Was Re: [Fwd: [C2] [Bug] ComponentNotAccessibleException])

Posted by Berin Loritsch <bl...@apache.org>.
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

Re: [Fwd: [C2] [Bug] ComponentNotAccessibleException]

Posted by Peter Donald <do...@apache.org>.
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                 |
*------------------------------------------------------*

Re: [Fwd: [C2] [Bug] ComponentNotAccessibleException]

Posted by Peter Donald <do...@apache.org>.
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                 |
*------------------------------------------------------*