I was wrong about what org.osgi.framework.storage.clean=onFirstInit was doing. It turns out that it is deleting the entire bundle cache directory and starting from scratch. I thought it was simply removing unused files and directories, which is less useful to me. I guess I was doing some wishful thinking.
So I guess I should ask a new question. Is there support for what I thought that option was doing? Basically, I want the caches for bundles that are still in use to survive, but anything else, especially caches for uninstalled bundles, to get removed. Some background: I cannot just nuke the bundle cache directory because some bundles have been previously installed from remote URLs, and I cannot repeat that operation every time the framework starts up. Bundles previously installed this way must be preserved. Also, a few times we have seen bundle cache directories get extremely bloated with caches for bundles that are no longer installed. On an embedded device this is catastrophic. Perhaps PackageAdmin.refreshPackages will solve this problem, but it's hard to test for sure because the problem has not been easily repeated. I have a workaround the looks for these directories manually, but the workaround is very Felix-specific and I try to avoid that sort of thing. Thanks for any help, Matt -----Original Message----- From: Matt Tennant [mailto:[email protected]] Sent: Wednesday, July 07, 2010 2:02 PM To: [email protected] Subject: RE: bundle cache version directories Hi all, I have a follow up question from this thread I started some time ago. Since then, I have been trying out the following property and value: org.osgi.framework.storage.clean=onFirstInit Which appears to work well, and removes extraneous directories and files from my bundle cache directory shortly after startup. Note that it doesn't matter whether these directories and files were originally created by Felix. If they are in the bundle cache directory, they are removed. I also tried calling refreshPackages(null) on the PackageAdmin service object at runtime. When I do this, the message "FrameworkEvent PACKAGES REFRESHED" is logged. It may be doing something, but the behavior is not the same as with the org.osgi.framework.storage.clean property. Extraneous directories and files are not removed. I was expecting the behavior to be the same between the two approaches. Can somebody please explain the distinction? Is there runtime access to the behavior that org.osgi.framework.storage.clean exhibits? In case there is some confusion, I am not worrying about precisely the same problem as in the original thread, but instead solving a problem where occasionally old bundle caches are present for bundles that are no longer in use. Thank you, Matt -----Original Message----- From: Richard S. Hall [mailto:[email protected]] Sent: Thursday, June 03, 2010 12:00 PM To: [email protected] Subject: Re: bundle cache version directories On 6/3/10 14:01, Matt Tennant wrote: > That was a useful read, thank you. It leaves me with just one question: > what triggers a framework refresh? (other than a startup/shutdown) > Explicitly calling PackageAdmin.refreshPackages(), which is done by getting the PackageAdmin service or the Felix shell provides a "refresh" command. -> richard > From this point onward I will make a note of whether I ever see multiple > version directories at a point in time when I should not. > > Thanks! > Matt > > -----Original Message----- > From: Richard S. Hall [mailto:[email protected]] > Sent: Thursday, June 03, 2010 5:50 AM > To: [email protected] > Subject: Re: bundle cache version directories > > On 6/2/10 19:20, Matt Tennant wrote: > >> Hi all, >> >> >> >> I have a question about the "versionX.X" directories inside the Felix >> bundle cache. I am using Felix 2.0.0, and I often see something like >> > the > >> following in my bundle cache directory: >> >> >> >> >> >>> ls -l >>> >>> >> bundle0 >> >> bundle1 >> >> ... >> >> >> >> >> >>> cd bundle0 >>> >>> >> >> >>> ls -l >>> >>> >> version0.1 >> >> version0.0 >> >> bundle.location >> >> bundle.startlevel >> >> bundle.lastmodified >> >> bundle.id >> >> bundle.state >> >> >> >> >> >>> ls -l version0.0 >>> >>> >> bundle.jar >> >> >> >>> ls -l version0.1 >>> >>> >> bundle.jar >> >> >> >> What I mean to be pointing out here are the two "bundle.jar" files in >> > two > >> different "versionX.X" directories in the cache area for one bundle. >> > What > >> is the reason that I might get more than one of these? How can I avoid >> that? I have limited space on the device our product runs on, and even >> the size of these jar files can make a difference. >> >> >> >> Note that I am using the autodeploy feature with actions >> "install,start,update". Sometimes the original bundle jars in the >> autodeploy directory change from one run to the next. >> >> > You might want to read: > > http://felix.apache.org/site/apache-felix-framework-bundle-cache.html > > Typically, what you are seeing is the result of doing updates. However, > typically the extra JAR files should be deleted after a refresh. > > Starting with "install,start,update" causes the update, but generally > i'd assume you'd autorefresh during startup so you wouldn't see > additional JAR files. Perhaps you could verify that refreshing is > deleting the JAR files. If so, you could verify that they are > automatically getting deleted on startup. > > By and large, after your framework starts I'd expect there to be no > additional JAR files and after it stops I'd expect there to be no > additional JAR files too. At run time, it just depends on whether you've > updated and not refreshed yet. > > -> richard > > >> >> Thanks, >> >> Matt >> >> >> >> >> >> > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
