[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[THREDDS #BRG-348930]: Collection caching problem - jdb files

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: [THREDDS #BRG-348930]: Collection caching problem - jdb files
  • Date: Tue, 08 Nov 2016 18:47:14 -0700
Hi Patrick,

Looks like this issue slipped through the cracks. Sorry about that.

> My understanding is that this entry in the threddsconfig.xml manages the 
> Berkely DB files.

Correct, but only the first two elements: "FeatureCollection.dir" and 
"FeatureCollection.maxSize". The function of the first one is obvious. The 
second one governs how much RAM is made available to the FeatureCollection 
cache. It does not control how many files are created on disk.

The remaining element, "FeatureCollection.RollingFileAppender", and it's 
children, control how FMRC status messages are logged by THREDDS. They have 
NOTHING to do with the .jdb cache files. Confusing, right? We've actually 
gotten rid of this element in THREDDS 5.0 [1].

My recommendation is to use the default values for everything in that section. 
To do so, you can set those values back manually or just delete (or 
comment-out) the entire section.

> Will this manage the jbd files and prevent them from filing up my cache again?

Really? You have a ton of .jdb files piling up? What does your directory look 
like? Can you give me an "ls"?

> Do I need to rebuild the Berkely DB?

No. Instead, delete the cache. Just do something like:

rm -r /usr/local/rtoper/tomcat/content/thredds/cache/collection/

The .jdb files will be recreated the next time you deploy thredds and access an 
FMRC. Note that those FMRCs may be slower to access the first time because the 
cached information about them is gone.

I'm not sure why you encountered that error after your coworker purged some of 
the .jdb files. Maybe because he didn't get them all? My advice is just to 
delete the directory and everything in it.

Cheers,
Christian

[1] https://github.com/Unidata/thredds/pull/676

Ticket Details
===================
Ticket ID: BRG-348930
Department: Support THREDDS
Priority: Critical
Status: Closed
===================
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata 
inquiry tracking system and then made publicly available through the web.  If 
you do not want to have your interactions made available in this way, you must 
let us know in each email you send to us.