ProvisionException already exists in repository #978
Comments
|
Sounds a bit like #663, but you probably know better if there is any relation between them. |
|
No this is sadly something different, this error is emitted by P2, while the other is emitted by the OS. |
|
Yes, I very occasionally see this problem in Oomph as well. But it's never possible to reproduce because if you try again, it succeeds. I suppose one could manually reproduce it by placing the artifact that will be download at the location where it will end up. Instead of failing though, p2 might handle it more gracefully and produce only a warning/log rather than fail the overall process; but should p2 overwrite the artifact or leave it as is? |
That's the question, I wonder what one would gain here to throw errors, at least at Tycho there is even code to first remove the descriptor and add it afterwards if it already exits, but still there is of course a window where a race could happen. |
I believe the fact that there is no clear answer what's best is the reason why an exception was the chosen behavior: at least one can't blame p2 for taking the wrong decision (ie installing an unexpected artifact, or corrupting an existing installation). Isn't the issue that multiple thread try to download the exact same file at the same time? If so, I imagine we can protect the code against that by putting some MirrorArtifact on hold if they happen to target the same destination as one currently running. Then upon completion of first mirror action, the next MirrorArtifact for this destination would check the target file signature/size and compare it to the ones expexted by p2 and continue if they are a match (which I think is most often the case). |
|
No, I don't think multiple threads are trying to download the same artifact. In general, the set of artifact requests is collected and requests are distributed across threads, but that's a comment about how p2 (and Oomph) use a transaction to update a profile. I don't know what Tycho is doing in this regard... I like the idea of comparing the artifacts. Obviously if they are equal such an issue could be quietly ignored... |
|
The problem is, to compare them one needs to download them, but as the download is rejected because the artifact already exits ... Also, Tycho here only emulates P2 (the error is from pure Tycho code!) and already has a "download lock" so the problem is probably more that the artifactrepositorymanager making the same thing available to different parts of the code and then it could be happen that things are not in sync anymore. |
|
We're experiencing the same on tycho 3.0.4. Sometimes the build is failing due to the below exception. Running it multiple times again later, works just fine. Kind regards,,
|
|
I encounter this issue as well with Tycho 4.0.2 frequently and first assumed it is a regression in the new version (but this issue proofs that wrong). We recently also changed to parallel builds so maybe the parallel resolution of dependencies is causing this problem? |
In a parallelized build I see the following exception
FYI @merks seems similar to what I recently encountered with Oomph
The text was updated successfully, but these errors were encountered: