I just did a simple check, and it seems that the bundles are correctly removed after the target application is undeployed, at least on the successful scenarios. The extra 2M size is caused by a .lazy.* file in the cache folder. and that file should be related to the store manager. Will check it further later ...
2011/7/23 Kevan Miller <[email protected]> > > On Jul 22, 2011, at 10:45 PM, Ivan wrote: > > > Suppose you mean the OSGi cache directory ? On the server runtime, the > size of this directory should be almost have the same size with the > repository folder, as all the files would be copied. > > Right. I'm not worried about relatively static content. I am worried about > consuming more and more disk space and never freeing it... > > > For the 12 GB var/cache directory size, there should be a leak issue > somewhere, > > There's definitely a leak. As mentioned, I see two megabytes leaked for > every deploy/undeploy of a very simple JSP web app. > > > a. In the deployment process, the deployer will deploy a temp bundle in > the cache for builder analysis, maybe it is not uninstalled correctly due to > some exceptions. > > b. In the undeployment process, Geronimo did not invoke uninstall for the > undeployed application due to unknown reason ? > > c. Some exported classes of the undeployed application are wired with > other bundles, so the OSGi runtime will keep it there until the framework is > restarted. Considering the current package generation mechanism, should not > happen. > > Think that if we could reproduce the issue, it should be easy to fix. > Also, I am also thinking that there is no need to package the temp bundle, > just use the target directory. which mentioned in another thread in the mail > list. > > It's extremely easy to recreate. Choose and application and deploy/undeploy > it a few times... 'du -h var/cache' or similar to monitor disk space between > iterations... > > --kevan -- Ivan
