Karaf cache

Tags: #<Tag:0x00007f2fb5f19b90>

Does anyone know if the Karaf cache can be limited in size and how that would work ?
I have not found any information on that. No answer even on Stack Overflow.
@splatch Lukasz any idea?

Hey Markus,
There are several places in regular karaf “data” directory. openHAB utilizes it as a “userdata”.
Regular “data” directory contains “cache”, “generated-bundles”, “pax-web-jsp”, “log” and “tmp” folders. Out of these the heaviest is “cache” and “log”. Sometimes a “kar” might occur as well. All other are usually empty or rather small in size.

In general cache will be subset of overall openhab size as it contains a copy of all JARs which are used in present state of environment. The only one way to limit its size is to reduce amount of installed modules. The size of logs is dependent on actual log4j configuration and can be adjusted in org.ops4j.pax.logging.cfg.
The reason why there is additional “cache” directory is caused by a way how OSGi works. You might install an module/bundle/jar from HTTP which is present for a limited time. Environment must get up after a restart thus it keeps copy of everything as latest snapshot (kind of).
Special case is a “kar” subdirectory which will retain KAR archives with addons and so on. Normally you can remove KAR contents once necessary modules are installed (you have to fetch it again next time). Initial thoughts about KAR was to extend a system directory (maven cache). First implementation was simply unpacked on top of Karaf installation but it led to multiple troubles with determinism of restart and clean cycles. Nowadays KAR, as far I know, should be an additional offline source for artifacts.

Hope that it helps. There are few additional sentences on how this directory works for Felix: https://felix.apache.org/documentation/subprojects/apache-felix-framework/apache-felix-framework-bundle-cache.html. Equinox philosophy might be somewhat different but still reflecting basic requirements.

Cheers,
Łukasz

Thanks for the insight.
My problem persist… I want to move everything which is written into (Z)RAM. That partition size I must provide in advance and there’s little to be wasted as it is specifically needed on RPis (to have only 1GB and SD cards).
Which to a major part IS the “cache” dir. So there is no inherent limit to the size the cache can grow to ? What would happen if disksize is reached - a cache must be able to invalidate its contents in this case, mustn’t it ? Is there any other means to forcibly reduce its footprint without changing the openHAB code of course ? Can I explicitly exclude individual (big) modules from being cached ?

Yes, there is no limit for “cache” size, it grows as needed and will not shrink due to above reasons. I am not aware of any trick which could change that. Normally once you run out of disk you will get regular java.io.IOException which will be linked to root cause - “no space left on device” or similar.

I think part of trouble could be… paperui and other user interfaces which might embed bunch of javascript which is not a java code and its packaged in such a way for distribution reasons and can safely by hosted directly from a disk. Otherwise it just takes a space. Not sure how much it does take after compression, but if you fight for kilobytes, it might be worth checking that. All UIs together might save you few megabytes.

In order to avoid the installation of these, you can try to use a different URI scheme. Maybe a file and reference combined together instead of mvn will behave differently. On pax-url webpage (library which handles mvn/war schemes).

Be aware that pax docs might not reflect the actual state of the universe.

I been building distro today and found following numbers:

  • org.openhab.ui.dashboard-2.5.0-20190823.072511-20.jar (418 kB)
  • org.openhab.ui.basic-2.5.0-20190823.072511-21.jar (1.4 MB)
  • org.openhab.ui.classic-2.5.0-20190823.072511-21.jar (332 kB)
  • org.openhab.ui.cometvisu-2.5.0-20190823.072511-21.jar (204 kB)
  • org.openhab.ui.cometvisu.php-2.5.0-20190823.072511-21.jar (9.5 kB)
  • org.openhab.ui.habmin-2.5.0-20190823.072511-21.jar (3.7 MB)
  • org.openhab.ui.habot-2.5.0-20190823.072511-21.jar (1.6 MB)
  • org.openhab.ui.habpanel-2.5.0-20190823.072511-21.jar (2.9 MB)
  • org.openhab.ui.homebuilder-2.5.0-20190823.072511-21.jar (398 kB)
  • org.openhab.ui.paper-2.5.0-20190823.072511-21.jar (935 kB)
  • org.openhab.ui.restdocs-2.5.0-20190823.072511-21.jar (952 kB)
  • org.openhab.ui.iconset.classic-2.5.0-20190823.072511-21.jar (883 kB)

The primary UIs are more than 10 megs of download and disk/cache size.