Bugzilla – Full Text Bug Listing
| Summary: | starting virgo from eclipse may produce "Destination path already exists" error | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [RT] Virgo | Reporter: | Pachara Tinamas <mrpachara> | ||||
| Component: | runtime | Assignee: | Borislav Kapukaranov <b.kapukaranov> | ||||
| Status: | CLOSED WORKSFORME | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | b.kapukaranov, glyn.normington, hsiliev | ||||
| Version: | unspecified | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows 7 | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Pachara Tinamas
Created attachment 195018 [details]
error log
Thanks for raising this. I tried 15 restarts from Eclipse and some stops+starts and it didn't reproduce with Virgo 2.1.1 on my Win7 machine.
What is interesting here is that the destination path is always deleted before trying to perform movement, as can be seen here:
private void stashContent() {
if (this.baseStagingPathReference.exists()) {
this.pastStagingPathReference.delete(true);
this.baseStagingPathReference.moveTo(this.pastStagingPathReference);
}
}
The call is performed in a single thread, so unless the windows FS returns and starts deleting separately I can't explain what's going on.
But it clearly sounds like a racing issue:
1. we call delete, the deletion is probably triggered
2. when we start moving the file is still not deleted, therefore the exception
Pachara, I'm curious when the problem occurs once, after that does it always reproduce? Cause it sounds like it shouldn't be always reproducible after the first time.
I tried that by stopping the startup with the debugger and when the pastDestination was deleted i created a new file for it. The server failed as described here but when i restarted it was fine again.
I don't see what we can do apart from adding a small timeout to allow any FS to complete the operation.
One thing you can try is optimizing the FS operations on your machine.
Is the issue occuring often?
Also i'm ruling out the long paths Win issue as the destination in this case is less than 220 characters long. The delete may return without actually removing the file if Windows decides to perform "delayed write". This may be the issue here - a file is not deleted, when the next Virgo startup is triggered. There is a try to delete the file at Virgo's startup - it is intentionally left there. The idea is to delete it only when there is an update to that bundle, so that the "past" version gets updated. Again, there isn't much we can do about this. Pachara you can try this hint: http://www.pcmag.com/article2/0,2817,1819756,00.asp on how to disable the "delayed write" and get back to us if it helps. I will try it. Thank You. Hi Pachara Did you get a chance to try it? It would be good to be able to progress this bug. Thanks, Glyn Closing as "cannot reproduce". Please re-open if the suggested workaround does not provide a solution. |