Community
Participate
Working Groups
If you use the director application and point to a file URI (-r file:///...), we will lock the location when the repository is first read. This is to ensure that nobody starts writing there at the same time. However, this means that a simple operation (like read a repository) has the side effect of creating a new file on disk. I'm opening this bug to discuss alternatives.
I see two options here: 1. Only lock when we actually perform a 'write' operation (add new artifact, change something, etc...). 2. Allow the director to create the repository as 'read-only', and don't use locks for 'read-only' repositories. Re #1. If you have multiple processes on the same machine accessing (reading and writing) a repository, you may read a corrupted repo. Of course, if you use http or some other protocol to read that repository, you may read a corrupted repo too. Re #2. This would have the same effect as #1 (you could read a corrupted repository), but this is little trickier to implement. We may need some new API (to load a repo as read only), and there is the question of side effects (what happens if I try to modify a read-only repo, should that be allowed)?
The permissions used when creating bot the lock file and the directories are also of great importance. I got an unpleasant surprise when I first used the director to install the repository and then started a hudson build that made an attempt to update it. The latter failed with a permission denied because the lock that was set by me during the director call wasn't removable by hudsonbuild.
Created attachment 192511 [details] Patch v1 This uses the actual artifact repository file (artifacs.jar/xml) as a read lock. The .lock file is still used when writing / modifying the repository. This is just the start of a solution, and I don't know if we will got this route, but I don't want to loose this work.
Created attachment 192512 [details] mylyn/context/zip
I've set the locking behaviour to 'off' by default (See bug#341826) with an option to enable it. The suitably ugly vm arg to enable it is: -Declipse.p2.internal.simple.artifact.repository.locking=true
I'm moving this out as locking is turned off by default, so this won't affect normal operation.
Move all 3.8 bugs to Juno.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
