On 22.06.2011 16:48, Alex Perry wrote: > If occasional 50x responses occur in batches, but not for most > simulation runs where you synchronize scenery, don't worry about it > and certainly don't blame the FGFS codebase. If 50x's occur routinely > for several hours, feel free to let me know. Just in case the shared > backend is misbehaving.
Not sure, but maybe related: I've recently seen lots of "ERROR 500" when using the bug tracker at code.google.com. Scenery is hosted on googlecode.com. So maybe google code is having issues (Could _Google_ really have traffic/performance trouble?? Is that possible for them... ;-) ). > Aside: I don't think terrasync (and thus probably the integrated > library) reschedules failed requests for a few minutes later; maybe it > should do so? Good idea. And indeed it doesn't. terrasync doesn't care if an update is successful or not. Directories are always blocked for several hours before another update attempt is allowed (or terrasync is restarted). It'd be trivial to change that, so that a directory only get's blocked for several minutes when the attempt failed, while we'd keep it blocked for hours if the update was successful. That wouldn't actively reschedule anything, but it would allow another attempt if the user again crossed (or circled in) the same area. That would improve things - and maybe that's even good enough. cheers, Thorsten ------------------------------------------------------------------------------ Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel