RE: cvs commit: jakarta-turbine-stratum/src/test-conf TestDiskCache.ccf

[James Taylor <jt...@4lane.com>]

On Sun, 2002-02-24 at 21:13, Aaron Smuts wrote:
> I guess you fixes the problem, but I suspected there may be an issue.
> You could change the order of the purgatory remove.  Check to see if it
> has been removed from purgatory where it is.  After writing to disk,
> remove from purgatory.  You can just put the remove at the end of the
> method to help.

That's pretty much what I did, although I reordered some things just so
it reads cleaner. But essentially it checks if it is spoolable, spools
it, and then removes it from purgatory.

> I've never noticed a problem though and I've hit is pretty hard.

It's probably a problem I introduced while refactoring.

> What exactly is wrong with the JISP disk cache?  I thought it was fairly
> close to working.

I haven't looked into it beyond that it failed the test. Chunks of keys
were being lost. Like, I write out 200 keys, and then get them back and
for some reason 35-70 are null. I'm afraid to make any assumptions about
that since the memory cache is also involved -- it needs further
investigation.

-- jt


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: cvs commit: jakarta-turbine-stratum/src/test-confTestDiskCache.ccf

[Aaron Smuts <aa...@verizon.net>]

> -----Original Message-----
> From: James Taylor [mailto:jtaylor@4lane.com]
> Sent: Sunday, February 24, 2002 9:18 PM
> To: 'Turbine Developers List'
> Subject: RE: cvs commit: jakarta-turbine-stratum/src/test-
> confTestDiskCache.ccf
> 
> On Sun, 2002-02-24 at 21:13, Aaron Smuts wrote:
> > I guess you fixes the problem, but I suspected there may be an
issue.
> > You could change the order of the purgatory remove.  Check to see if
it
> > has been removed from purgatory where it is.  After writing to disk,
> > remove from purgatory.  You can just put the remove at the end of
the
> > method to help.
> 
> That's pretty much what I did, although I reordered some things just
so
> it reads cleaner. But essentially it checks if it is spoolable, spools
> it, and then removes it from purgatory.

Good.  Sorry I haven't looked at the changes yet.

> 
> > I've never noticed a problem though and I've hit is pretty hard.
> 
> It's probably a problem I introduced while refactoring.

You're too generous. :)

> 
> > What exactly is wrong with the JISP disk cache?  I thought it was
fairly
> > close to working.
> 
> I haven't looked into it beyond that it failed the test. Chunks of
keys
> were being lost. Like, I write out 200 keys, and then get them back
and
> for some reason 35-70 are null. I'm afraid to make any assumptions
about
> that since the memory cache is also involved -- it needs further
> investigation.

Hmmn.  

I noticed some problems with the comparison, the equals? Method, of the
JispKey that I created, but I thought I fixed them.  

I originally had a problem with incorrect equivalence.  I thought
performance was the only problem.

Could it be the same purgatory ordering issue?  Jisp writes will take
longer.

Aaron



> 
> -- jt
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:turbine-dev-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:turbine-dev-
> help@jakarta.apache.org>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>