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

Reply via email to