You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Davanum Srinivas <di...@yahoo.com> on 2001/02/23 17:19:15 UTC
[C2] Problem with component pools.
Berin,
The "pools" Hashmap in both CocoonComponentSelector and DefaultComponentManager are keyed off the
just the Class and *NOT* the hint/role. The hint/role is ignored completely when we do a pools.get
or a pools.put. (For example in DefaultComponentManager lines 261 and 279)
The problem is with SVGSerializer which acts both as "svg2jpeg" and "svg2png". We always get the
same pool back as pools Hashmap uses the class SVGSerializer as the key.
Thanks,
dims
=====
Davanum Srinivas, JNI-FAQ Manager
http://www.jGuru.com/faq/JNI
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices! http://auctions.yahoo.com/
Re: [C2] Problem with component pools.
Posted by Berin Loritsch <bl...@apache.org>.
Paul Russell wrote:
>
> * Berin Loritsch (bloritsch@apache.org) wrote :
> > Quick and easy one:
> > Simply use a different class. In other words why not have a
> > PngSvgSerializer and a JpegSvgSerializer that wraps up the
> > configurations necessary for explicitly making it use the different
> > formats. That is the _easy_ way.
>
> Yep. Not ideal though.
>
> > Another simple and easy method is a wrapper that lets the Pool "mark"
> > the client silently to the end user. Although without moving to JDK
> > 1.3 and the Proxy interface, this would quickly become an unweildy
> > solution.
>
> Mm-hmm. What's the position on using 1.3 features in C2? Though it
> doesn't cause me any problems, JDK1.3 isn't available on all platforms,
> so this might not be feasible yet.
Last time it was discussed (late last year), the bottom line was don't
do it yet. When JDK 1.3 is available on all platforms (or at least
BSD ones), then we can address it.
The other thing was don't force the upgrade until there is something
we _need_ in JDK 1.3. That Trove package Pier pointed out requires
JDK 1.3 in parts--so if we used that, it would force an upgrade.
>
> I've just checked out the references stuff, and I don't think it helps
> afterall. From what I can tell, the references only get enqueued _after_
> they're cleared. It's one of those weird APIs that appears to be more or
> less useless by design :/
>
> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2] Problem with component pools.
Posted by Paul Russell <pa...@luminas.co.uk>.
* Berin Loritsch (bloritsch@apache.org) wrote :
> Quick and easy one:
> Simply use a different class. In other words why not have a
> PngSvgSerializer and a JpegSvgSerializer that wraps up the
> configurations necessary for explicitly making it use the different
> formats. That is the _easy_ way.
Yep. Not ideal though.
> Another simple and easy method is a wrapper that lets the Pool "mark"
> the client silently to the end user. Although without moving to JDK
> 1.3 and the Proxy interface, this would quickly become an unweildy
> solution.
Mm-hmm. What's the position on using 1.3 features in C2? Though it
doesn't cause me any problems, JDK1.3 isn't available on all platforms,
so this might not be feasible yet.
I've just checked out the references stuff, and I don't think it helps
afterall. From what I can tell, the references only get enqueued _after_
they're cleared. It's one of those weird APIs that appears to be more or
less useless by design :/
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: [C2] Problem with component pools.
Posted by Berin Loritsch <bl...@apache.org>.
Paul Russell wrote:
>
> * Berin Loritsch (bloritsch@apache.org) wrote :
> > Davanum Srinivas wrote:
> > >
> > > Berin,
> > >
> > > The "pools" Hashmap in both CocoonComponentSelector and DefaultComponentManager are keyed off the
> > > just the Class and *NOT* the hint/role. The hint/role is ignored completely when we do a pools.get
> > > or a pools.put. (For example in DefaultComponentManager lines 261 and 279)
> > >
> > > The problem is with SVGSerializer which acts both as "svg2jpeg" and "svg2png". We always get the
> > > same pool back as pools Hashmap uses the class SVGSerializer as the key.
> > I see the problem. This is much like the issue with ThreadSafe
> > Components that was solved before. In theory, every hint reflects a
> > distinct Class. In practice, we can have a single class that has
> > differing configuration information. It is more efficient to pool
> > already set up components instead of virgin components--otherwise we
> > loose the benefit of pooling.
> >
> > Ok, We will make the ComponentManager/Selector be keyed off the
> > role/hint every time. This is the classic question of distinction:
> > When is a Component a different Role/Hint and when is it the same
> > Role/Hint? The practical answer is this:
> >
> > Any time a Component has to be made distinct (i.e. serialize to PNG
> > vs. JPG, or the different Selectors we have floating around), it needs
> > to be completely distinct by role or hint down to the instance
> > retrieved from the ComponentManager/Selectors.
>
> Indeed. One slight complication is that when we get the component back
> in the release method, we have no way of determining its hint. I guess
> the best way around this is to use a Map:
>
> public void release(Component comp) {
> if ( comp instanceof Poolable ) {
> ((ComponentPool)componentTracker.get(comp)).put(comp);
> componentTracker.remove(comp);
> }
> // [...]
> }
>
> ..although this creates housekeeping complications when people forget to
> release their components. We could use a weak reference to find out when
> a component dies, and nuke the componentTracker entry for the component,
> although this means keeping a Set full of references and regularly
> checking the reference queue for dead components. Urgh. Any better
> ideas?
Quick and easy one:
Simply use a different class. In other words why not have a PngSvgSerializer
and a JpegSvgSerializer that wraps up the configurations necessary for explicitly
making it use the different formats. That is the _easy_ way.
Another simple and easy method is a wrapper that lets the Pool "mark" the client
silently to the end user. Although without moving to JDK 1.3 and the Proxy
interface, this would quickly become an unweildy solution.
Re: [C2] Problem with component pools.
Posted by Paul Russell <pa...@luminas.co.uk>.
* Berin Loritsch (bloritsch@apache.org) wrote :
> Davanum Srinivas wrote:
> >
> > Berin,
> >
> > The "pools" Hashmap in both CocoonComponentSelector and DefaultComponentManager are keyed off the
> > just the Class and *NOT* the hint/role. The hint/role is ignored completely when we do a pools.get
> > or a pools.put. (For example in DefaultComponentManager lines 261 and 279)
> >
> > The problem is with SVGSerializer which acts both as "svg2jpeg" and "svg2png". We always get the
> > same pool back as pools Hashmap uses the class SVGSerializer as the key.
> I see the problem. This is much like the issue with ThreadSafe
> Components that was solved before. In theory, every hint reflects a
> distinct Class. In practice, we can have a single class that has
> differing configuration information. It is more efficient to pool
> already set up components instead of virgin components--otherwise we
> loose the benefit of pooling.
>
> Ok, We will make the ComponentManager/Selector be keyed off the
> role/hint every time. This is the classic question of distinction:
> When is a Component a different Role/Hint and when is it the same
> Role/Hint? The practical answer is this:
>
> Any time a Component has to be made distinct (i.e. serialize to PNG
> vs. JPG, or the different Selectors we have floating around), it needs
> to be completely distinct by role or hint down to the instance
> retrieved from the ComponentManager/Selectors.
Indeed. One slight complication is that when we get the component back
in the release method, we have no way of determining its hint. I guess
the best way around this is to use a Map:
public void release(Component comp) {
if ( comp instanceof Poolable ) {
((ComponentPool)componentTracker.get(comp)).put(comp);
componentTracker.remove(comp);
}
// [...]
}
..although this creates housekeeping complications when people forget to
release their components. We could use a weak reference to find out when
a component dies, and nuke the componentTracker entry for the component,
although this means keeping a Set full of references and regularly
checking the reference queue for dead components. Urgh. Any better
ideas?
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: [C2] Problem with component pools.
Posted by Berin Loritsch <bl...@apache.org>.
Davanum Srinivas wrote:
>
> Berin,
>
> The "pools" Hashmap in both CocoonComponentSelector and DefaultComponentManager are keyed off the
> just the Class and *NOT* the hint/role. The hint/role is ignored completely when we do a pools.get
> or a pools.put. (For example in DefaultComponentManager lines 261 and 279)
>
> The problem is with SVGSerializer which acts both as "svg2jpeg" and "svg2png". We always get the
> same pool back as pools Hashmap uses the class SVGSerializer as the key.
Hmmm.
I see the problem. This is much like the issue with ThreadSafe Components that was solved before.
In theory, every hint reflects a distinct Class. In practice, we can have a single class that has
differing configuration information. It is more efficient to pool already set up components instead
of virgin components--otherwise we loose the benefit of pooling.
Ok, We will make the ComponentManager/Selector be keyed off the role/hint every time. This is the
classic question of distinction: When is a Component a different Role/Hint and when is it the same
Role/Hint? The practical answer is this:
Any time a Component has to be made distinct (i.e. serialize to PNG vs. JPG, or the different Selectors
we have floating around), it needs to be completely distinct by role or hint down to the instance
retrieved from the ComponentManager/Selectors.