You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Tim Williams <wi...@gmail.com> on 2006/02/12 21:46:52 UTC
questions on store usage
In forrest we've got an input module that currently has it's own
simple hashmap-caching. The assumption is that the right thing to do
is move away from our homegrown-cache to use the cocoon store
(TRANSIENT_STORE). In doing this, I've got some potentially dumb
questions.
Is the store somehow magically isolated or is it a global environment
thing? In other words do I need to prefix my keys with the input
module name to attempt to attain uniqueness?
Do I need to do anything on dispose() to explicitly clean out my
stored items or assume it'll push them out if it needs to?
Also, if you can think of anything that uses the store in this way
that I could use as an example I'd appreciate it -- I've yet to find
anything.
Thanks,
--tim
Re: questions on store usage
Posted by Joerg Heinicke <jo...@gmx.de>.
Sorry, but I read this message only now.
On 20.02.2006 07:46, David Crossley wrote:
> Tim Williams wrote:
>> In forrest we've got an input module that currently has it's own
>> simple hashmap-caching. The assumption is that the right thing to do
>> is move away from our homegrown-cache to use the cocoon store
>> (TRANSIENT_STORE).
>
> I presume that you are referring to the Locationmap.
>
> The Cocoon LinkRewriterTransformer has a similar issue
> http://issues.apache.org/jira/browse/COCOON-1574
> "Memory Leak with XMLFileModule"
>
> It has comments about needing to use the Cocoon cache.
> Perhaps Ralph and Jörg can help.
On the one hand it is simply a matter of avoiding copy & paste or
reimplementations of concerns in different ways (of which some might be
buggy like with XMLFileModule). On the other hand the Cocoon cache is
well tested and works well - while the XMLFileModule cache does
obviously not. ...
>> Do I need to do anything on dispose() to explicitly clean out my
>> stored items or assume it'll push them out if it needs to?
... The Cocoon core especially moves objects from transient store to
persistent store if the transient store is full - or to nirvana if they
are not serializable. At least the store does not grow endlessly and
does not lead to OutOfMemoryError.
So yes, switching to Cocoon cache is preferable to homegrown caches.
For the Cocoon issue itself: Few days ago Ralph mentioned possible
progress "in the next couple of days". Unfortunately, it seems he had
not the time to make it, so it is not in Cocoon 2.1.9. But from other
mails on the list I assume there will be a new release in the near
future (be it 2.1.9.1 or 2.1.10) anyway. Hopefully including the fix
then. Any comments on this, Ralph?
Regards
Jörg
Re: questions on store usage
Posted by Tim Williams <wi...@gmail.com>.
On 2/20/06, David Crossley <cr...@apache.org> wrote:
> I am answering so as to keep the thread alive,
> not because i know anything about stores.
>
> Would someone who does know, please help Tim.
> Being a Forrest committer, when we get him over the
> learning hump, he might be able to help fix various
> Cocoon issues.
>
> Tim Williams wrote:
> > In forrest we've got an input module that currently has it's own
> > simple hashmap-caching. The assumption is that the right thing to do
> > is move away from our homegrown-cache to use the cocoon store
> > (TRANSIENT_STORE).
>
> I presume that you are referring to the Locationmap.
>
> The Cocoon LinkRewriterTransformer has a similar issue
> http://issues.apache.org/jira/browse/COCOON-1574
> "Memory Leak with XMLFileModule"
>
> It has comments about needing to use the Cocoon cache.
> Perhaps Ralph and Jörg can help.
>
> > In doing this, I've got some potentially dumb
> > questions.
>
> Nothing is dumb.
>
> > Is the store somehow magically isolated or is it a global environment
> > thing? In other words do I need to prefix my keys with the input
> > module name to attempt to attain uniqueness?
>
> See a Cocoon status page and the Key id for various keys
> in the current caches. Yes it needs to be unique.
> http://cocoon.zones.apache.org/demos/release/samples/
>
> There are docs at
> "CacheableProcessingComponent Contracts"
> http://cocoon.zones.apache.org/daisy/documentation/writing/corecontracts/675.html
>
> "Performance Tips"
> http://cocoon.apache.org/2.1/performancetips.html
> ... has some about the keys.
>
> > Do I need to do anything on dispose() to explicitly clean out my
> > stored items or assume it'll push them out if it needs to?
>
> The store mechanism will take care of itself according to our
> configuration. At Forrest we ae just using the default config
> provided by Cocoon. Perhaps we need to tweak that.
>
> Here is a reading list, in case you had missed some :-)
> Not sure how up-to-date any of it is. Also Forrest
> is using Cocoon-2.2 (prior to Mavenisation) so will be
> different.
>
> "Writing Cache Efficient Components"
> http://cocoon.zones.apache.org/daisy/documentation/writing/690.html
>
> "Cocoon Source Resolving - Store Components"
> http://cocoon.apache.org/2.1/developing/stores.html
>
> "Caching"
> http://cocoon.apache.org/2.1/userdocs/concepts/caching.html
>
> "StoreJanitor"
> http://cocoon.apache.org/2.1/userdocs/concepts/storejanitor.html
>
> -David
Thanks David,
After getting a little further, I have come to understand that the
default transient store (MRUMemoryStore) can't handle null values[1]
which we need for caching locationmap entries. The only answer so far
(thanks Ralph) has been to create our own store. Since all our input
module needs to cache is simple strings, I don't, at this point, think
it's worth creating a custom store for forrest.
--tim
[1] - http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=113995314926899&w=2
Re: questions on store usage
Posted by David Crossley <cr...@apache.org>.
I am answering so as to keep the thread alive,
not because i know anything about stores.
Would someone who does know, please help Tim.
Being a Forrest committer, when we get him over the
learning hump, he might be able to help fix various
Cocoon issues.
Tim Williams wrote:
> In forrest we've got an input module that currently has it's own
> simple hashmap-caching. The assumption is that the right thing to do
> is move away from our homegrown-cache to use the cocoon store
> (TRANSIENT_STORE).
I presume that you are referring to the Locationmap.
The Cocoon LinkRewriterTransformer has a similar issue
http://issues.apache.org/jira/browse/COCOON-1574
"Memory Leak with XMLFileModule"
It has comments about needing to use the Cocoon cache.
Perhaps Ralph and Jörg can help.
> In doing this, I've got some potentially dumb
> questions.
Nothing is dumb.
> Is the store somehow magically isolated or is it a global environment
> thing? In other words do I need to prefix my keys with the input
> module name to attempt to attain uniqueness?
See a Cocoon status page and the Key id for various keys
in the current caches. Yes it needs to be unique.
http://cocoon.zones.apache.org/demos/release/samples/
There are docs at
"CacheableProcessingComponent Contracts"
http://cocoon.zones.apache.org/daisy/documentation/writing/corecontracts/675.html
"Performance Tips"
http://cocoon.apache.org/2.1/performancetips.html
... has some about the keys.
> Do I need to do anything on dispose() to explicitly clean out my
> stored items or assume it'll push them out if it needs to?
The store mechanism will take care of itself according to our
configuration. At Forrest we ae just using the default config
provided by Cocoon. Perhaps we need to tweak that.
Here is a reading list, in case you had missed some :-)
Not sure how up-to-date any of it is. Also Forrest
is using Cocoon-2.2 (prior to Mavenisation) so will be
different.
"Writing Cache Efficient Components"
http://cocoon.zones.apache.org/daisy/documentation/writing/690.html
"Cocoon Source Resolving - Store Components"
http://cocoon.apache.org/2.1/developing/stores.html
"Caching"
http://cocoon.apache.org/2.1/userdocs/concepts/caching.html
"StoreJanitor"
http://cocoon.apache.org/2.1/userdocs/concepts/storejanitor.html
-David
> Also, if you can think of anything that uses the store in this way
> that I could use as an example I'd appreciate it -- I've yet to find
> anything.
>
> Thanks,
> --tim