You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Rick Tessner <ri...@dingle.myra.com> on 2001/07/20 18:47:10 UTC

Re: Are we ready for C2 Beta 2 yet [ Still MRUMemoryStore probs ]

On Fri, 20 Jul 2001 11:37:42 EDT, Berin Loritsch wrote:

>I know we talked about a CVS freeze earlier this week (or was that last week?)
>.  Is the current CVS ready for a release at this time?  I think the last
>issues were MRUMemmoryStore bug fixes.

Hello all,

It looks like there's still a bit of a problem with the MRUMemoryStore.
It's only happening if the fs store is used.

The reading and writing of cached files are looking in different places.
Basically, the calls to fsstore.get() and fsstore.store() are using
different parameters.  The call to fsstore.store() is adding in
the cachedir path and the call to fsstore.get() isn't.

I've attached a Q&D patch to this and it works ...

BUT I've also noticed that the cache keys are used by other methods
such as remove().  

This patch is assuming that the key and the file on the filesystem are in fact
the same thing.  Is that the intent?  The keys now being passed to the store()
and get() methods look like this:

  cache-dir-prefix/PCK%3ACCK%3A3-html-1PCK%3...

rather than just

  PCK%3ACCK%3A3-html-1PCK%3...
 
Other methods would not be getting the cache-dir-prefix/ .  Are the
cache keys intended to look like filesystem-like things? Or are
the keys supposed to be some abstraction of that?

Anyway, here's the quick & dirty patch that'll get the fs store working.



AW: Are we ready for C2 Beta 2 yet [ Still MRUMemoryStore probs ]

Posted by Gerhard Froehlich <g-...@gmx.de>.
Please ignore my last mail. I get this mail from you at the same
time I send mine.
>It looks like there's still a bit of a problem with the MRUMemoryStore.
>It's only happening if the fs store is used.
Seems like.
>The reading and writing of cached files are looking in different places.
>Basically, the calls to fsstore.get() and fsstore.store() are using
>different parameters.  The call to fsstore.store() is adding in
>the cachedir path and the call to fsstore.get() isn't.
Yes that is right, it is careless bug from me.
>I've attached a Q&D patch to this and it works ...
Thanx, but you forgot to fix the remove() method.
>BUT I've also noticed that the cache keys are used by other methods
>such as remove().
yes you're right
>This patch is assuming that the key and the file on the filesystem are in
fact
>the same thing.  Is that the intent?  The keys now being passed to the
store()
>and get() methods look like this:
>cache-dir-prefix/PCK%3ACCK%3A3-html-1PCK%3...
>rather than just
>PCK%3ACCK%3A3-html-1PCK%3...

>Other methods would not be getting the cache-dir-prefix/ .  Are the
>cache keys intended to look like filesystem-like things? Or are
>the keys supposed to be some abstraction of that?
no no, this really a bug. I fixed yesterday the path determination and
forgot
to append it on the other methods.
>Anyway, here's the quick & dirty patch that'll get the fs store working.
Thank you very much. But I would like to send a patch with the whole fixes
when this is ok.



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org