This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 32089

Summary: Reimplement the caching framework.
Product: obsolete Reporter: Martin Entlicher <mentlicher>
Component: vcscoreAssignee: Martin Entlicher <mentlicher>
Status: RESOLVED FIXED    
Severity: blocker CC: anebuzelsky, pkuzel, rkubacki, ttran
Priority: P1 Keywords: PERFORMANCE
Version: 3.x   
Hardware: All   
OS: All   
URL: http://vcscore.netbeans.org/doc/cache/index.html
Issue Type: TASK Exception Reporter:
Bug Depends on: 44216    
Bug Blocks: 26096, 28223, 28774, 32193, 32345, 34137, 34153, 34280, 34772, 34776, 34795, 36643, 36928, 37679, 39817, 40423, 41012, 41141, 41715    

Description Martin Entlicher 2003-03-18 13:58:54 UTC
According to issue #32065:
It is not reasonable to write data to disk in
ReferenceQueue handler. The handler shlould do
fast cleanup, not backup of "lost" data. What if
the IDE was ended without releasing (and thus
saving) the data?
Comment 1 Martin Entlicher 2003-08-01 15:18:00 UTC
I'm generalizing this task and scheduling to NetBeans 4.0.

There are more problems connected to the caching framework that should
be addressed in the next release.

These are mainly improved testeability and usability of
org.netbeans.modules.vcscore.cache.* package, that should re-design
the public classes and methods to make implementations easier and
better distinguish provided functionality and functionality, that is
expected from the implementations. This will also improved
testeability. It should be possible to write unit tests.

Also performance should be improved. Access to disk cache should be
minimized. It must be paid atention not to do more work, that is
really necessary. Ideally, performance tests should be written.

If a disk cache is corrupted, it should recover automatically (clean
the garbage and force refresh to have fresh data).

Adding depending issues.
Comment 2 Martin Entlicher 2003-08-19 16:59:06 UTC
Starting to work on it...
Branch "cache_32089" created in vcscore module (with
"cache_32089_base" as the base). The re-design will be made in that
branch.

Comment 3 Martin Entlicher 2003-11-14 10:48:46 UTC
Branch cache_32089 was created from prj40_prototype branch. Therefore
this branch is unusable in the main trunk (it was not intended to do
this in trunk when I started to work on it).

But now, the cache redesign is necessary for 3.6 release. Therefore
I've created a new branch cache_32089_1 (with base tag
cache_32089_1_base) from current trunk in vcscore module.

The development of the new caching framework is moved to cache_32089_1
branch.
Comment 4 Martin Entlicher 2004-01-05 14:01:45 UTC
Unfortunately, the cache redesign is not doable in 3.6 timeframe. We
have feature freeze at the end of this week and there are still some
UI issues pending.
Therefore I'm rescheduling this to promotion D.
Comment 5 Antonin Nebuzelsky 2004-03-18 11:44:53 UTC
Martin, what's your current plan with regard to the cache
reimplementation? Do you have an idea if/when it will be available for
promo-D? Thanks.
Comment 6 Martin Entlicher 2004-05-20 17:12:45 UTC
Unfortunately it will most likely not be implemented into promotion-D.
We are in a stabilization period and this is considered to be a risky
change in this timeframe. It's scheduled for promotion-E.
Also API review is in progress (issue #43637).
Comment 7 _ pkuzel 2004-09-02 12:25:37 UTC
FYI (copy from issue #43637)

I'm working on cache implementation simplification. It uses Map like
interface: 
  + void set(FileKey, FileStatus)
  + FileStatus getCached(FileKey)
  + void add/removeListener(l)

and utility methods:
  + FileStatus get(FileKey)  // may connect to repository
  + FileStatus getFresh(FileKey) // connects and caches result

and utility class IgnoreList   
  + bool isIgnored(FileKey)

There is also AbstractFileSystem integration method that allows to
trace FileObject's lifetime (and derived FileKey lifetime).
  + FileReference createFileReference()

FileKey is currently FileObjct itself but it seems to lack uniquess
and I'll replace it by FileUtil.toFile(fo).getAbsolutePath().
Prototype is being developed in vcscore.turbo package.

If it prove successfull it'd affect this issue a lot.
Comment 8 Martin Entlicher 2005-01-05 19:35:31 UTC
The cache was finally redesigned and implemented according to
http://vcscore.netbeans.org/doc/cache/context.html document.
Committed to trunk today by Petr Kuzel.