Bugzilla – Full Text Bug Listing
| Summary: | Numerous outdated bundledata/configuration files created in equinox stack | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Eric Hsu <mfhsu> | ||||||||||||
| Component: | Framework | Assignee: | Thomas Watson <tjwatson> | ||||||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||||||
| Severity: | normal | ||||||||||||||
| Priority: | P3 | CC: | liukl, rogalski, tjwatson, tomhsu, xhhsld | ||||||||||||
| Version: | 3.4 | Keywords: | helpwanted | ||||||||||||
| Target Milestone: | Juno M1 | ||||||||||||||
| Hardware: | PC | ||||||||||||||
| OS: | All | ||||||||||||||
| Whiteboard: | |||||||||||||||
| Bug Depends on: | |||||||||||||||
| Bug Blocks: | 353880 | ||||||||||||||
| Attachments: |
|
||||||||||||||
|
Description
Eric Hsu
Do you think you could work on a patch? Otherwise this will not make 3.5. Hi...Thomas Unfortunately, we do not have the resource nor expertise to address this problem. What's your plan to fix this issue if it's not in 3.5? Thanks Created attachment 132641 [details]
patch
Without any help the solution is going to very minimal. This patch simply cleans up the files on every save. It does this only if the existing configuration property osgi.embedded.cleanupOnOpen is set to true.
I will consider releasing this fix, but only after I get confirmation back that this actually solves your issues.
We are observing similar issues with release jars: org.eclipse.osgi_3.4.2.R34x_v20080826-1230.jar We are seeing huge number of files such as: .bundledata.YYY .state.XXX .lazy.ZZZ in directory <CONFIG>/org.eclipse.osgi/ folder. We are not bouncing the OSGi framework either. Would this patch work to address the growth in that folder? If this is a separate problem. Please let me know. (In reply to comment #4) > We are observing similar issues with release jars: > org.eclipse.osgi_3.4.2.R34x_v20080826-1230.jar > > We are seeing huge number of files such as: > .bundledata.YYY > .state.XXX > .lazy.ZZZ > in directory <CONFIG>/org.eclipse.osgi/ folder. > > We are not bouncing the OSGi framework either. > > Would this patch work to address the growth in that folder? > > If this is a separate problem. Please let me know. This could be a similar issue, but I am concerned by the statement "We are seeing huge nubmer of files such as:". How many is huge? These files should only be written if the state of the set of bundles installed in the framework is changing. Are you doing a lot of continuous operations that install/uninstall/update bundles or even persistently start/stop or set the start-level of the bundles? Even if you are doing this continuously we should not be writing these files unless a period of 30 seconds has passed with no activity. So I would not expect huge amounts of these files to appear very quickly. Any idea how long it takes to get the huge number of files? Also are you never shutting down the framework? If you do shutdown the framework how are you doing so? Upon proper shutdown we should be cleaning up these extra files. This patch may be able to help but I would like to understand your scenario a bit before determining that this is the right fix for you. We have been running equinox w/o bouncing the JVM for 9 days now. We are seeing the triplet files (.lazy .bundledata and .state) increment from 1 to 1959 now. The du -sh in the <CONFIG>/org.eclipse.osgi directory now stands at 1004MB. Scenario we are running equinox: We are using equinox as a server to run custom jobs that conform to a specification on a time schedule. Within an hour, we are running ~500 executions. These executions/jobs are backed from 50 bundles with unique symbolic names. I believe that we install these bundles on the first execution. Subsequent execution of the jobs w/ same symbolic names update the bundle (via bundle.update). For an hour, we should be seeing ~500 bundle.update calls. Ideally, we are not going to shutdown the server by design. Thanks, Tom (In reply to comment #6) > We have been running equinox w/o bouncing the JVM for 9 days now. We are seeing > the triplet files (.lazy .bundledata and .state) increment from 1 to 1959 now. > The du -sh in the <CONFIG>/org.eclipse.osgi directory now stands at 1004MB. > > Scenario we are running equinox: > We are using equinox as a server to run custom jobs that conform to a > specification on a time schedule. Within an hour, we are running ~500 > executions. These executions/jobs are backed from 50 bundles with unique > symbolic names. I believe that we install these bundles on the first execution. > Subsequent execution of the jobs w/ same symbolic names update the bundle (via > bundle.update). For an hour, we should be seeing ~500 bundle.update calls. > > Ideally, we are not going to shutdown the server by design. > > Thanks, > Tom I suspect this patch would be able to help you. I would be curious if the files get cleaned up when you do shutdown the framework. (In reply to comment #7) > I suspect this patch would be able to help you. I would be curious if the > files get cleaned up when you do shutdown the framework. I tried the patch. And put in some debug output to let me know if it is making a difference. However, it is not. I do not see the code calling the cleanup method inside save proposed by the patch. And I still see the files keep getting generated in org.eclipse.osgi: drwxr-xr-x 5 thsu g900 4096 Jun 14 11:48 .. drwxr----- 5 thsu g900 4096 Jun 14 11:49 bundles -rw-r----- 1 thsu g900 16908 Jun 14 11:49 .state.1 -rw-r----- 1 thsu g900 379991 Jun 14 11:49 .lazy.1 -rw-r----- 1 thsu g900 46171 Jun 14 11:49 .bundledata.1 -rw-r----- 1 thsu g900 16908 Jun 14 11:50 .state.2 -rw-r----- 1 thsu g900 379991 Jun 14 11:50 .lazy.2 -rw-r----- 1 thsu g900 46171 Jun 14 11:50 .bundledata.2 -rw-r----- 1 thsu g900 16908 Jun 14 11:51 .state.3 -rw-r----- 1 thsu g900 379991 Jun 14 11:51 .lazy.3 -rw-r----- 1 thsu g900 46171 Jun 14 11:51 .bundledata.3 -rw-r----- 1 thsu g900 16908 Jun 14 11:53 .state.4 drwxr----- 2 thsu g900 4096 Jun 14 11:53 .manager -rw-r----- 1 thsu g900 379991 Jun 14 11:53 .lazy.4 -rw-r----- 1 thsu g900 46171 Jun 14 11:53 .bundledata.4 .... growing over time What else can I try to have the system clean up the files lower than .bundledata./.lazy./.state.MAX_NUM? my config.ini looks like: #Configuration File #Fri May 09 14:20:34 EDT 2008 osgi.bundles=org.eclipse.equinox.common@2:start, org.eclipse.update.configurator@3:start, org.eclipse.core.runtime@start osgi.bundles.defaultStartLevel=4 osgi.instance.area.default=@user.dir/workspace #osgi.framework=platform:/base/plugins/org.eclipse.osgi osgi.configuration.cascaded=false osgi.framework.extensions=com.custom.osgi.adapters eclipse.noRegistryCache=true osgi.clean=true osgi.embedded.cleanupOnOpen=true osgi.embedded.cleanTempFiles=true # End of file marker - must be here eof=eof Thanks. (In reply to comment #7) > I suspect this patch would be able to help you. I would be curious if the > files get cleaned up when you do shutdown the framework. The .lazy,bundledata,state do not get cleaned up upon shutdown. It gets cleaned up on restart. After further testing, I finally figured out why the initial patch does not work. Simply call cleanup() method inside save() again will lead to a 2nd attempt on locking with locker.lock which will fail inside cleanup. I wrote another cleanupWithLock() for use inside save(). now i see only the highest level of triplet files. the lower generation files are gone. only see: .lazy.MAX .bundledate.MAX .state.MAX thanks for the help. (In reply to comment #10) > After further testing, I finally figured out why the initial patch does not > work. > > Simply call cleanup() method inside save() again will lead to a 2nd attempt on > locking with locker.lock which will fail inside cleanup. > > I wrote another cleanupWithLock() for use inside save(). now i see only the > highest level of triplet files. the lower generation files are gone. > only see: > .lazy.MAX > .bundledate.MAX > .state.MAX > > thanks for the help. Actually one more thing. Is this patch available on later releases? (In reply to comment #10) > After further testing, I finally figured out why the initial patch does not > work. > > Simply call cleanup() method inside save() again will lead to a 2nd attempt on > locking with locker.lock which will fail inside cleanup. > > I wrote another cleanupWithLock() for use inside save(). now i see only the > highest level of triplet files. the lower generation files are gone. > only see: > .lazy.MAX > .bundledate.MAX > .state.MAX > > thanks for the help. Thanks you! Could you attach an updated patch with your changes? (In reply to comment #11) > Actually one more thing. Is this patch available on later releases? No, unfortunately I did not get any response from my question in comment 3. "I will consider releasing this fix, but only after I get confirmation back that this actually solves your issues." But now that you are interested in testing and fixing this properly I plan to address this in the next release. We can also consider backporting to 3.7.1 after getting more testing done. Thanks for you help. Created attachment 198199 [details]
this is the resulting modified StorageManager.java that I had working.
this is the resulting modified StorageManager.java that I had working. This is a workaround with cleanupWithLock() method inside save().
Created attachment 198200 [details]
diff file to change from original to my version
Above diff.txt is the result of the below command:
[thsu@tom-linux: /scratch/thsu/osgi342/source_mod/org/eclipse/osgi/storagemanager] $ diff StorageManager.java.original StorageManager.java > diff.txt
Hopefully the two files uploaded are helpful for you to consider a patch.
Created attachment 198334 [details]
updated patch and test
Here is an updated patch. I decided to update the private cleanup method to take a boolean to determine if it should lock/release. There was an existing bug in the StorageManager that would prevent it from opening if osgi.embedded.cleanupOnOpen was set to true.
Created attachment 199147 [details]
updated patch and tests
Updated patch against head.
Released latest patch for Juno. Tom, is this something you would want backported for 3.7.1. If so I will open a separate bug to consider for 3.7.1. Comment on attachment 198200 [details]
diff file to change from original to my version
Thanks for the patch!
(In reply to comment #17) > Released latest patch for Juno. > > Tom, is this something you would want backported for 3.7.1. If so I will open > a separate bug to consider for 3.7.1. Yes pls if the 3.7.1 is the next release drop that we can get the changes. Hi, is it better to use tempClean flag ? As from the name of osgi.embedded.cleanupOnOpen, it means to clean up the file while starting the storemanager (usually while starting the framework) ? Also, it seems that an exception will be thrown if the repository folder is deleted, as no lock file there when cleanupOnOpen is configured. (In reply to comment #20) > Hi, is it better to use tempClean flag ? As from the name of > osgi.embedded.cleanupOnOpen, it means to clean up the file while starting the > storemanager (usually while starting the framework) ? > Also, it seems that an exception will be thrown if the repository folder is > deleted, as no lock file there when cleanupOnOpen is configured. Hmm, seems that the exception I mean is fixed after moving the codes of locking file. (In reply to comment #20) > Hi, is it better to use tempClean flag ? As from the name of > osgi.embedded.cleanupOnOpen, it means to clean up the file while starting the > storemanager (usually while starting the framework) ? I don't think using the tempClean flag is the correct flag to use. This is really intended to clean up .tmp files that may have been left around from a crash. Perhaps a new flag osgi.embedded.cleanupOnSave is needed. > Also, it seems that an exception will be thrown if the repository folder is > deleted, as no lock file there when cleanupOnOpen is configured. I fixed this in the attachment 199147 [details] that got released to master. I opened bug353879 to consider adding a cleanupOnSave option. Thanks, a new flag is better. Also, could you please help to port this change to 3.7 branch ? Thanks. (In reply to comment #24) > Thanks, a new flag is better. Also, could you please help to port this change > to 3.7 branch ? Thanks. Yes, that will happen in bug353880. |