Would you mind detailing the process in a more detailed fashion? Load induced delay shouldn't make the process fail, only take more time. Failures like this make me think there's a flaw in the design and while increasing the delay may be a working workaround, it's not completly errorproof and it slows things down during off-peak hours for no good reasons.
Yann Le 20 mars 09 à 00:38, Tom Hughes a écrit : > Gordon Dey wrote: >> I just saw this with a 55KB file. Specifically: >> >> Unable to open /store/gpx/traces/336906.gpx (errno=No such file >> or directory) >> XML parser at line 0 column 0 >> >> Looks, to the uninitiated observer, like the file was CREAT-d, but >> not actually >> filled in. Perhaps there is a file-system-full (or quota) condition >> being struck? > > How exactly do you reach that, clearly erroneous, conclusion? If the > file had been created you wouldn't be able to get a "No such file > error" > would you... > > There is a race condition that can cause this to happen, as we have to > add the record to the database before we can rename the file to it's > final name, but the importer deliberately ignores any recently added > files to avoid triggering that. > > My best guess is that the delay isn't long enough under particular > load > conditions and that we may need to increase it. > > Tom > > -- > Tom Hughes ([email protected]) > http://www.compton.nu/ > > _______________________________________________ > talk mailing list > [email protected] > http://lists.openstreetmap.org/listinfo/talk _______________________________________________ talk mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk
