OnDemand User Group
Support Forums => MP Server => Topic started by: yousuf_gani on June 19, 2017, 07:34:55 AM
-
Hi
I use Ondemand 9.5.0.6
I see many Objects are created under CACHE folder "36950" (date not recognized by arsdate)
eg : /opt/ondemand/data/cache/<instancename>/36950/VNA/DOC/184FAAA
$ arsdate -a 36950 => Failed
Could you please help to know below 2 points
1) How the CACHE folder naming are done. Its based on the SEGMENT Field DATE + CACHE Retention value or Based on other ?
- As I did the LOAD(on 6/16/2017) whose LOAD id: "5096-12-0-3FAA-20170421000000-20170421000000-5097" based on the SEGMENT Field date value "20170421" with CACHE retention of Just "2 days".
- But the CACHE folder created with "17368" : 3FAAA -> /odcache/UAT/01/XXXXXX/17368/GBA/DOC/3FAAA
$ arsdate -a 17368 => 07/20/17
- Not possible to understand how this date got calculated. Even though I set with CACHE retention to 2 days, not able to delete/expire CACHE even after -n 0 -x 1.
2) How the CACHE retention are calculated and applied to these Object in the FOLDER to delete via ARSMAINT -c.
Please help to Under the CACHE folder naming and expiration process.
-
Originally, IBM CMOD dates could only be between 1970 and 2069 - a limitation that's been removed with the addition of native database date fields. However, there are still a few leftovers from those days. An Application Group with the old 'date/time' fields can only represent dates out to 2038 or so. And if you have a cache-only system, and you've (ever) entered "36525" in the 'Life of Data and Indexes' parameter in the Application Group definitions, you've likely run into an overflow situation -- the current date + 100 years = a number bigger than Content Manager OnDemand can handle.
This is probably still an IBM CMOD bug -- you'd be best to open a PMR and ask for some guidance.
Also, just for the record, the numeric directory name (17368) you mentioned used to be the date an entire directory would expire -- this is, again, a remnant of a time when I/O bandwidth was painfully slow, and you wouldn't ever want to review each and every file in the cache -- but instead, you'd want to delete a whole directory of documents that were eligible for expiration. That isn't the case anymore -- disk I/O is blazing-fast -- so verifying the entire cache filesystem, looking for documents to delete is a reasonably fast task. Because you have some numbers are beyond what IBM CMOD's arsdate command can handle, it's best to call IBM to find out how to deal with this.
Don't forget to report back and let us know how you solved this issue!
-JD.