You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@sundn.de> on 2001/02/21 10:46:33 UTC
[C2]: Component Pooling and recycling
Using the latest cvs of C2, I have the following questions/remarks to the component pooling:
Questions first:
1. Looking up a component using the ComponentManager:
- Am I right that when the component is not Poolable I always get the same instance?
- When the component is Poolable (or PoolClient) is it the response of the "looking up component" to put it back into the pool ?
2. Is it correct that Actions are never pooled or recycled?
Now the remarks:
3. If a sitemap component is only Recyclable (without Poolable or PoolClient) it is not recycled.
4. If a sitemap component is only Poolable but not PoolClient it is not put back into the pool.
I would suggest to change the behaviour of 3. and 4. that Recyclable sitemap components are always recycled and that Poolable sitemap components are alyways returned to the pool - regardless if they declare PoolClient or not.
If there are no objections against the changes I will do them.
Carsten
Open Source Group sunShine - Lighting up e:Business
================================================================
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
www.sundn.de mailto:cziegeler@sundn.de
================================================================
Re: [C2]: Component Pooling and recycling
Posted by Berin Loritsch <bl...@apache.org>.
Giacomo Pati wrote:
>
> Berin Loritsch wrote:
> > Carsten Ziegeler wrote:
> > > Using the latest cvs of C2, I have the following questions/remarks to the
> > > component pooling:
> > >
> > > Questions first:
> > > 1. Looking up a component using the ComponentManager:
> > > - Am I right that when the component is not Poolable I always get the
> > > same instance?
> >
> > No. Some are Factory components and are created fresh each time. If it is
> > marked ThreadSafe, then you should get the same instance everytime.
> >
> > > - When the component is Poolable (or PoolClient) is it the response of
> > > the "looking up component" to put it back into the pool ?
> >
> > Unfortunately, that is the way it is. This does not change even when we
> > are using the Pool interface like it was meant to be used (get/put).
> > BTW: the "looking up component" is called a Composer--it even has an
> > interface.
> >
> > > 2. Is it correct that Actions are never pooled or recycled?
> >
> > Yes. They are ThreadSafe by design, and so should be one instance for all
> > time.
> >
> > > Now the remarks:
> > >
> > > 3. If a sitemap component is only Recyclable (without Poolable or
> > > PoolClient) it is not recycled.
> >
> > True. Recyclable does not necessarily mean Poolable (Not sure of the
> > reasoning, but that's the way the framework is set up). The recycle()
> > method is used to "reset" the component back to it's original status.
>
> Take a look at the Recyclable interface! It extends Poolable.
The issue is that we need to differentiate between the two types of
Components _without_ bringing it back to ground zero. We might try
a Reconfigurable interface that might make it more worthwile. The
question is how to get the right Configuration object to the component
instance.
>
> Giacomo (Still 187 mails to read)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
AW: [C2]: Component Pooling and recycling
Posted by Carsten Ziegeler <cz...@sundn.de>.
> Giacomo Pati [mailto:giacomo@apache.org] wrote:
> Berin Loritsch wrote:
> > Carsten Ziegeler wrote:
> > > Using the latest cvs of C2, I have the following questions/remarks to
> the
> > > component pooling:
> > >
> > > Questions first:
> > > 1. Looking up a component using the ComponentManager:
> > > - Am I right that when the component is not Poolable I always get
> the
> > > same instance?
> >
> > No. Some are Factory components and are created fresh each time. If it
> is
> > marked ThreadSafe, then you should get the same instance everytime.
> >
> > > - When the component is Poolable (or PoolClient) is it the response
> of
> > > the "looking up component" to put it back into the pool ?
> >
> > Unfortunately, that is the way it is. This does not change even when we
> > are using the Pool interface like it was meant to be used (get/put).
> > BTW: the "looking up component" is called a Composer--it even has an
> > interface.
> >
> > > 2. Is it correct that Actions are never pooled or recycled?
> >
> > Yes. They are ThreadSafe by design, and so should be one instance for
> all
> > time.
> >
> > > Now the remarks:
> > >
> > > 3. If a sitemap component is only Recyclable (without Poolable or
> > > PoolClient) it is not recycled.
> >
> > True. Recyclable does not necessarily mean Poolable (Not sure of the
> > reasoning, but that's the way the framework is set up). The recycle()
> > method is used to "reset" the component back to it's original status.
>
> Take a look at the Recyclable interface! It extends Poolable.
Arghhhh, sorry for this stupid thread - I never saw the "extends Poolable" line...
Perhaps its time to wear glaces...or take some time off....
Carsten
Re: [C2]: Component Pooling and recycling
Posted by Giacomo Pati <gi...@apache.org>.
Berin Loritsch wrote:
> Carsten Ziegeler wrote:
> > Using the latest cvs of C2, I have the following questions/remarks to the
> > component pooling:
> >
> > Questions first:
> > 1. Looking up a component using the ComponentManager:
> > - Am I right that when the component is not Poolable I always get the
> > same instance?
>
> No. Some are Factory components and are created fresh each time. If it is
> marked ThreadSafe, then you should get the same instance everytime.
>
> > - When the component is Poolable (or PoolClient) is it the response of
> > the "looking up component" to put it back into the pool ?
>
> Unfortunately, that is the way it is. This does not change even when we
> are using the Pool interface like it was meant to be used (get/put).
> BTW: the "looking up component" is called a Composer--it even has an
> interface.
>
> > 2. Is it correct that Actions are never pooled or recycled?
>
> Yes. They are ThreadSafe by design, and so should be one instance for all
> time.
>
> > Now the remarks:
> >
> > 3. If a sitemap component is only Recyclable (without Poolable or
> > PoolClient) it is not recycled.
>
> True. Recyclable does not necessarily mean Poolable (Not sure of the
> reasoning, but that's the way the framework is set up). The recycle()
> method is used to "reset" the component back to it's original status.
Take a look at the Recyclable interface! It extends Poolable.
Giacomo (Still 187 mails to read)
Re: [C2]: Component Pooling and recycling
Posted by Berin Loritsch <bl...@apache.org>.
Carsten Ziegeler wrote:
>
> Using the latest cvs of C2, I have the following questions/remarks to the component pooling:
>
> Questions first:
> 1. Looking up a component using the ComponentManager:
> - Am I right that when the component is not Poolable I always get the same instance?
No. Some are Factory components and are created fresh each time. If it is marked ThreadSafe,
then you should get the same instance everytime.
> - When the component is Poolable (or PoolClient) is it the response of the "looking up component" to put it back into the pool ?
Unfortunately, that is the way it is. This does not change even when we are using the
Pool interface like it was meant to be used (get/put).
BTW: the "looking up component" is called a Composer--it even has an interface.
> 2. Is it correct that Actions are never pooled or recycled?
Yes. They are ThreadSafe by design, and so should be one instance for all time.
> Now the remarks:
>
> 3. If a sitemap component is only Recyclable (without Poolable or PoolClient) it is not recycled.
True. Recyclable does not necessarily mean Poolable (Not sure of the reasoning, but that's the
way the framework is set up). The recycle() method is used to "reset" the component back to
it's original status.
> 4. If a sitemap component is only Poolable but not PoolClient it is not put back into the pool.
That is an unfortunate side effect of the way the current ComponentManager/Selector interface is.
If they had a put() method to return the Component on general principle, then it would make for
a more elegant solution. The temporary solution is to make anything that is Poolable a PoolClient.
> I would suggest to change the behaviour of 3. and 4. that Recyclable sitemap components are always recycled and that Poolable sitemap components are alyways returned to the pool - regardless if they declare PoolClient or not.
They used to be simply Poolable, and not PoolClients. The PoolClients were created as a method of
actually returning the Components to the Pool. Otherwise what we have is a factory method that simply
creates more and more components all the time. What's worse, they have a reference on them in the pool,
so they are never garbage collected.
Any Poolable client should be made PoolClients, and any usage of a PoolClient should call the returnToPool
method. Also, the recycle() method is called by the ComponentPool. In any other context, it's really not
useful.
> If there are no objections against the changes I will do them.
The Pool code does need to be optimized, but let's standardize on all Poolable Components should be
PoolClients--otherwise you will find that no Component can be returned to the pool without a reference
to the pool.
Re: AW: [C2]: Component Pooling and recycling
Posted by Berin Loritsch <bl...@apache.org>.
Berin Loritsch wrote:
>
> That was my thinking when I created the PoolClient interface. I would
> really like the ComponentManager/Selector interfaces to remain "pure".
> Especially since that is the way they are cast in the whole of Cocoon.
> Your proposed solution will cause us to be required to cast as
> CocoonComponentSelector--which is not a guarantee. We should lobby
> Avalon for the change to the official interface--and use PoolClient
> in the mean time.
I have requested the interface change in the Avalon-dev list, we will
discuss it, and hopefully it will be Ok'd quickly.
Re: AW: [C2]: Component Pooling and recycling
Posted by Giacomo Pati <gi...@apache.org>.
Carsten Ziegeler wrote:
> > Berin Loritsch [mailto:bloritsch@apache.org] wrote:
> >
> > Carsten Ziegeler wrote:
> > > > * Paul Russell wrote
> > > >
> > > > * Carsten Ziegeler (cziegeler@sundn.de) wrote :
> > > > > > * Carsten Ziegeler (cziegeler@sundn.de) wrote :
> > > > > > > I would suggest to change the behaviour of 3. and 4. that
> >
> > Recyclable
> >
> > > > > > > sitemap components are always recycled and that Poolable
> > > > > > > sitemap components are alyways returned to the pool -
> > > > > > > regardless if they declare PoolClient or not.
> > > > > >
> > > > > > How do you propose doing the last?
> > > > >
> > > > > The ResourcePipeline currently gets the sitemap components
> >
> > out of the
> >
> > > > pool
> > > >
> > > > > and puts them back if they declare PoolClient. I would add at that
> >
> > point
> >
> > > > > an additional test for Poolable and Recyclable. The
> > > >
> > > > SitemapComponentSelector
> > > >
> > > > > must be extended by a put-method() for this.
> > > >
> > > > Uhuh. Might make more sense to add the 'put' method to the
> > > > CocoonComponentSelector, which is where all the pooling code seems to
> > > > be.
> > >
> > > Ohh, yes the CocoonComponentSelector is the one.
> > >
> > > > Other than that, I have no major problem with it. I still think the
> > > > Avalon ComponentManager interface needs changing so that it contains
> > > > a 'put' method, however. Anything that can 'compose' a component
> > > > should
> >
> > be
> >
> > > > able to 'put' it back afterwards. Everything we're doing to get
> > > > around this looks like a hack to me.
> > >
> > > Yes, exactly. This hacking is the reason why I am asking first - I
> >
> > thought that I perhaps had overlooked something.
> >
> > > So I think, we should do the hack first and then when a corrected
> >
> > ComponentManager is available we can remove it.
> >
> > That was my thinking when I created the PoolClient interface. I would
> > really like the ComponentManager/Selector interfaces to remain "pure".
> > Especially since that is the way they are cast in the whole of Cocoon.
> > Your proposed solution will cause us to be required to cast as
> > CocoonComponentSelector--which is not a guarantee. We should lobby
> > Avalon for the change to the official interface--and use PoolClient
> > in the mean time.
>
> Ok then, this means using PoolClient instead of Poolable everywhere and
> everything works fine.
>
> What about the Recyclable components? Is it correct, that a Recyclable
> component can be used without Poolable (or PoolClient) ? If so, who is
> responsible for calling recycle() ?
IIRC the Recyclable interface extends Poolable.
Giacomo (still 194 mail to read from this list :)
>
> Carsten
>
>
> C
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
AW: [C2]: Component Pooling and recycling
Posted by Carsten Ziegeler <cz...@sundn.de>.
> Berin Loritsch [mailto:bloritsch@apache.org]wrote:
>
> Ok, Carsten, you can go to town now. Every time a Component is
> Selected or
> LookedUp, we need to Release them. I made the initial changes
> with the new
> ComponentManager/ComponentSelector changes, but I didn't go so far as to
> remove PoolClient....
>
Great work Berin! And you also removed the PoolClient! Thanks!
(Sorry that I currently have absolutely no time for C2 to help on that - work's very busy)
Carsten
Re: AW: [C2]: Component Pooling and recycling
Posted by Berin Loritsch <bl...@apache.org>.
Berin Loritsch wrote:
>
> Carsten Ziegeler wrote:
> >
> > > Berin Loritsch [mailto:bloritsch@apache.org] wrote:
> > >
> > > > What about the Recyclable components? Is it correct, that a Recyclable
> > > > component can be used without Poolable (or PoolClient) ? If so, who is
> > > > responsible for calling recycle() ?
> > >
> > > The ComponentPool is responsible for calling recycle(). However, since
> > > you already have a reference to the Component, you can reuse it as long
> > > as you call recycle() between each use.
> > >
> > Then I would suggest do add a test for Recyclable in the ResourcePipeline
> > to recycle a component which is not PoolClient.
Ok, Carsten, you can go to town now. Every time a Component is Selected or
LookedUp, we need to Release them. I made the initial changes with the new
ComponentManager/ComponentSelector changes, but I didn't go so far as to
remove PoolClient....
Re: AW: [C2]: Component Pooling and recycling
Posted by Berin Loritsch <bl...@apache.org>.
Carsten Ziegeler wrote:
>
> > Berin Loritsch [mailto:bloritsch@apache.org] wrote:
> >
> > > What about the Recyclable components? Is it correct, that a Recyclable
> > > component can be used without Poolable (or PoolClient) ? If so, who is
> > > responsible for calling recycle() ?
> >
> > The ComponentPool is responsible for calling recycle(). However, since
> > you already have a reference to the Component, you can reuse it as long
> > as you call recycle() between each use.
> >
> Then I would suggest do add a test for Recyclable in the ResourcePipeline
> to recycle a component which is not PoolClient.
Really not necessary. If we get a Component from the ComponentManager that
is not a PoolClient, it is never returned to the Pool. Therefore it is never
used again. The recycle() method in this case is completely orthagonal. It
has no real use.
AW: [C2]: Component Pooling and recycling
Posted by Carsten Ziegeler <cz...@sundn.de>.
> Berin Loritsch [mailto:bloritsch@apache.org] wrote:
>
> > What about the Recyclable components? Is it correct, that a Recyclable
> > component can be used without Poolable (or PoolClient) ? If so, who is
> > responsible for calling recycle() ?
>
> The ComponentPool is responsible for calling recycle(). However, since
> you already have a reference to the Component, you can reuse it as long
> as you call recycle() between each use.
>
Then I would suggest do add a test for Recyclable in the ResourcePipeline
to recycle a component which is not PoolClient.
Carsten
Re: AW: [C2]: Component Pooling and recycling
Posted by Berin Loritsch <bl...@apache.org>.
Carsten Ziegeler wrote:
>
> > Berin Loritsch [mailto:bloritsch@apache.org] wrote:
> >
> > Carsten Ziegeler wrote:
> > >
> > > > * Paul Russell wrote
> > > >
> > > > * Carsten Ziegeler (cziegeler@sundn.de) wrote :
> > > > > > * Carsten Ziegeler (cziegeler@sundn.de) wrote :
> > > > > > > I would suggest to change the behaviour of 3. and 4. that
> > Recyclable
> > > > > > > sitemap components are always recycled and that Poolable sitemap
> > > > > > > components are alyways returned to the pool - regardless if they
> > > > > > > declare PoolClient or not.
> > > > > > How do you propose doing the last?
> > > > > The ResourcePipeline currently gets the sitemap components
> > out of the
> > > > pool
> > > > > and puts them back if they declare PoolClient. I would add at that
> > point
> > > > > an additional test for Poolable and Recyclable. The
> > > > SitemapComponentSelector
> > > > > must be extended by a put-method() for this.
> > > >
> > > > Uhuh. Might make more sense to add the 'put' method to the
> > > > CocoonComponentSelector, which is where all the pooling code seems to
> > > > be.
> > > >
> > > Ohh, yes the CocoonComponentSelector is the one.
> > >
> > > > Other than that, I have no major problem with it. I still think the
> > > > Avalon ComponentManager interface needs changing so that it contains a
> > > > 'put' method, however. Anything that can 'compose' a component should
> > be
> > > > able to 'put' it back afterwards. Everything we're doing to get around
> > > > this looks like a hack to me.
> > > >
> > > Yes, exactly. This hacking is the reason why I am asking first - I
> > thought that I perhaps had overlooked something.
> > >
> > > So I think, we should do the hack first and then when a corrected
> > ComponentManager is available we can remove it.
> >
> > That was my thinking when I created the PoolClient interface. I would
> > really like the ComponentManager/Selector interfaces to remain "pure".
> > Especially since that is the way they are cast in the whole of Cocoon.
> > Your proposed solution will cause us to be required to cast as
> > CocoonComponentSelector--which is not a guarantee. We should lobby
> > Avalon for the change to the official interface--and use PoolClient
> > in the mean time.
> >
> Ok then, this means using PoolClient instead of Poolable everywhere and everything works fine.
>
> What about the Recyclable components? Is it correct, that a Recyclable component can be used without Poolable (or PoolClient) ? If so, who is responsible for calling recycle() ?
The ComponentPool is responsible for calling recycle(). However, since
you already have a reference to the Component, you can reuse it as long
as you call recycle() between each use.
AW: [C2]: Component Pooling and recycling
Posted by Carsten Ziegeler <cz...@sundn.de>.
> Berin Loritsch [mailto:bloritsch@apache.org] wrote:
>
> Carsten Ziegeler wrote:
> >
> > > * Paul Russell wrote
> > >
> > > * Carsten Ziegeler (cziegeler@sundn.de) wrote :
> > > > > * Carsten Ziegeler (cziegeler@sundn.de) wrote :
> > > > > > I would suggest to change the behaviour of 3. and 4. that
> Recyclable
> > > > > > sitemap components are always recycled and that Poolable sitemap
> > > > > > components are alyways returned to the pool - regardless if they
> > > > > > declare PoolClient or not.
> > > > > How do you propose doing the last?
> > > > The ResourcePipeline currently gets the sitemap components
> out of the
> > > pool
> > > > and puts them back if they declare PoolClient. I would add at that
> point
> > > > an additional test for Poolable and Recyclable. The
> > > SitemapComponentSelector
> > > > must be extended by a put-method() for this.
> > >
> > > Uhuh. Might make more sense to add the 'put' method to the
> > > CocoonComponentSelector, which is where all the pooling code seems to
> > > be.
> > >
> > Ohh, yes the CocoonComponentSelector is the one.
> >
> > > Other than that, I have no major problem with it. I still think the
> > > Avalon ComponentManager interface needs changing so that it contains a
> > > 'put' method, however. Anything that can 'compose' a component should
> be
> > > able to 'put' it back afterwards. Everything we're doing to get around
> > > this looks like a hack to me.
> > >
> > Yes, exactly. This hacking is the reason why I am asking first - I
> thought that I perhaps had overlooked something.
> >
> > So I think, we should do the hack first and then when a corrected
> ComponentManager is available we can remove it.
>
> That was my thinking when I created the PoolClient interface. I would
> really like the ComponentManager/Selector interfaces to remain "pure".
> Especially since that is the way they are cast in the whole of Cocoon.
> Your proposed solution will cause us to be required to cast as
> CocoonComponentSelector--which is not a guarantee. We should lobby
> Avalon for the change to the official interface--and use PoolClient
> in the mean time.
>
Ok then, this means using PoolClient instead of Poolable everywhere and everything works fine.
What about the Recyclable components? Is it correct, that a Recyclable component can be used without Poolable (or PoolClient) ? If so, who is responsible for calling recycle() ?
Carsten
C
Re: AW: [C2]: Component Pooling and recycling
Posted by Berin Loritsch <bl...@apache.org>.
Carsten Ziegeler wrote:
>
> > * Paul Russell wrote
> >
> > * Carsten Ziegeler (cziegeler@sundn.de) wrote :
> > > > * Carsten Ziegeler (cziegeler@sundn.de) wrote :
> > > > > I would suggest to change the behaviour of 3. and 4. that Recyclable
> > > > > sitemap components are always recycled and that Poolable sitemap
> > > > > components are alyways returned to the pool - regardless if they
> > > > > declare PoolClient or not.
> > > > How do you propose doing the last?
> > > The ResourcePipeline currently gets the sitemap components out of the
> > pool
> > > and puts them back if they declare PoolClient. I would add at that point
> > > an additional test for Poolable and Recyclable. The
> > SitemapComponentSelector
> > > must be extended by a put-method() for this.
> >
> > Uhuh. Might make more sense to add the 'put' method to the
> > CocoonComponentSelector, which is where all the pooling code seems to
> > be.
> >
> Ohh, yes the CocoonComponentSelector is the one.
>
> > Other than that, I have no major problem with it. I still think the
> > Avalon ComponentManager interface needs changing so that it contains a
> > 'put' method, however. Anything that can 'compose' a component should be
> > able to 'put' it back afterwards. Everything we're doing to get around
> > this looks like a hack to me.
> >
> Yes, exactly. This hacking is the reason why I am asking first - I thought that I perhaps had overlooked something.
>
> So I think, we should do the hack first and then when a corrected ComponentManager is available we can remove it.
That was my thinking when I created the PoolClient interface. I would
really like the ComponentManager/Selector interfaces to remain "pure".
Especially since that is the way they are cast in the whole of Cocoon.
Your proposed solution will cause us to be required to cast as
CocoonComponentSelector--which is not a guarantee. We should lobby
Avalon for the change to the official interface--and use PoolClient
in the mean time.
AW: [C2]: Component Pooling and recycling
Posted by Carsten Ziegeler <cz...@sundn.de>.
> * Paul Russell wrote
>
> * Carsten Ziegeler (cziegeler@sundn.de) wrote :
> > > * Carsten Ziegeler (cziegeler@sundn.de) wrote :
> > > > I would suggest to change the behaviour of 3. and 4. that Recyclable
> > > > sitemap components are always recycled and that Poolable sitemap
> > > > components are alyways returned to the pool - regardless if they
> > > > declare PoolClient or not.
> > > How do you propose doing the last?
> > The ResourcePipeline currently gets the sitemap components out of the
> pool
> > and puts them back if they declare PoolClient. I would add at that point
> > an additional test for Poolable and Recyclable. The
> SitemapComponentSelector
> > must be extended by a put-method() for this.
>
> Uhuh. Might make more sense to add the 'put' method to the
> CocoonComponentSelector, which is where all the pooling code seems to
> be.
>
Ohh, yes the CocoonComponentSelector is the one.
> Other than that, I have no major problem with it. I still think the
> Avalon ComponentManager interface needs changing so that it contains a
> 'put' method, however. Anything that can 'compose' a component should be
> able to 'put' it back afterwards. Everything we're doing to get around
> this looks like a hack to me.
>
Yes, exactly. This hacking is the reason why I am asking first - I thought that I perhaps had overlooked something.
So I think, we should do the hack first and then when a corrected ComponentManager is available we can remove it.
Carsten
Re: AW: [C2]: Component Pooling and recycling
Posted by Paul Russell <pa...@luminas.co.uk>.
* Carsten Ziegeler (cziegeler@sundn.de) wrote :
> > * Carsten Ziegeler (cziegeler@sundn.de) wrote :
> > > I would suggest to change the behaviour of 3. and 4. that Recyclable
> > > sitemap components are always recycled and that Poolable sitemap
> > > components are alyways returned to the pool - regardless if they
> > > declare PoolClient or not.
> > How do you propose doing the last?
> The ResourcePipeline currently gets the sitemap components out of the pool
> and puts them back if they declare PoolClient. I would add at that point
> an additional test for Poolable and Recyclable. The SitemapComponentSelector
> must be extended by a put-method() for this.
Uhuh. Might make more sense to add the 'put' method to the
CocoonComponentSelector, which is where all the pooling code seems to
be.
Other than that, I have no major problem with it. I still think the
Avalon ComponentManager interface needs changing so that it contains a
'put' method, however. Anything that can 'compose' a component should be
able to 'put' it back afterwards. Everything we're doing to get around
this looks like a hack to me.
Paul.
cc Avalon-dev
--
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
AW: [C2]: Component Pooling and recycling
Posted by Carsten Ziegeler <cz...@sundn.de>.
> * Carsten Ziegeler (cziegeler@sundn.de) wrote :
> > I would suggest to change the behaviour of 3. and 4. that Recyclable
> > sitemap components are always recycled and that Poolable sitemap
> > components are alyways returned to the pool - regardless if they
> > declare PoolClient or not.
>
> How do you propose doing the last?
>
The ResourcePipeline currently gets the sitemap components out of the pool
and puts them back if they declare PoolClient. I would add at that point
an additional test for Poolable and Recyclable. The SitemapComponentSelector
must be extended by a put-method() for this.
Carsten
Open Source Group sunShine - Lighting up e:Business
================================================================
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
www.sundn.de mailto:cziegeler@sundn.de
================================================================
Re: [C2]: Component Pooling and recycling
Posted by Paul Russell <pa...@luminas.co.uk>.
* Carsten Ziegeler (cziegeler@sundn.de) wrote :
> I would suggest to change the behaviour of 3. and 4. that Recyclable
> sitemap components are always recycled and that Poolable sitemap
> components are alyways returned to the pool - regardless if they
> declare PoolClient or not.
How do you propose doing the last?
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