Hi Richard, Thank you for your quick response, as usual.
I hope you are right. I am going to keep that refreshPackages call in there after any uninstall and monitor it for awhile. When I try to test the prodecure myself, it doesn't seem to matter whether I call refreshPackages or not after an uninstall, the bundle's cache is gone. Since I cannot recreate the problem where multiple bundle caches are not cleaned up I don't know whether this will help when it happens again. Thanks, Matt -----Original Message----- From: Richard S. Hall [mailto:[email protected]] Sent: Wednesday, July 07, 2010 3:20 PM To: [email protected] Subject: Re: bundle cache version directories On 7/7/10 6:12 PM, Matt Tennant wrote: > 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. A refresh operation will do that. If you are not seeing this behavior, then either you are doing something wrong or you uncovered a bug. The correct procedure is to uninstall some bundles, call refreshPackages(), after which the uninstalled bundles should be removed from the cache. -> richard > 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] > --------------------------------------------------------------------- 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]
