Please note that the problem on my ROMA server has not yet been fixed. The server is building a new db, but it's taking time since it's also handing out client requests. The disk array has been very busy the last two days. :)
I figured it would be better to leave the server online due to the large queue that builds up when clients are handling prio 2 requests. I can take it down though if everyone agrees that would be better, although it's almost finished with the new db at this point. -Jeremy > -----Original Message----- > From: Rowland Shaw [mailto:rowland.s...@gmail.com] > Sent: Tuesday, December 16, 2008 8:06 AM > To: Milenko > Cc: Brett Henderson; OSM-Dev Openstreetmap > Subject: Re: [OSM-dev] Osmarender not always showing latest data > > Looks like osmarender is doing something odd again: > http://www.openstreetmap.org/?lat=51.5443&lon=0.75487&zoom=16&layers=0B > 00FTTT > > And this time a re-render from informationfreeway is not fixing it :( > (It appears to have lost a bunch of fixes I did around 2008-11-27 > 21:25:52). Bizarrely the Mapnik layer is better in this area... > > > 2008/12/16 Milenko <mile...@king-nerd.com>: > >> mile...@king-nerd.com wrote: > >>> I haven't figured out how the server got out of sync with the main > api > >>> yet. My best guess is that I somehow missed part of a day or a few > hours > >>> when I initially brought the server online. If I remember > correctly the > >>> timeframes are about the same. > >>> > >> Okay, hopefully it was a once off. > >>> The only issue I've had with --rci was during the api outtage last > >>> weekend. The main server produced a 0-byte minute diff during the > >>> outtage and osmosis wouldn't scan past that file. I had to apply > the > >>> hourly diff and then go from there. > >>> > >> Can you let me know if this happens again? That seems odd. I > should > >> never create 0 byte diffs. At a minimum they should be 110 bytes > which is > >> an osmChange file containing no data. I don't update the server > timestamp > >> until a diff file is successfully generated and available. That way > >> clients should never download an invalid file. The only exception > to this > >> is when utf-8 issues crop up in the main db and osmosis generates a > dodgy > >> file on the server that can't be processed. > >> > > > > If it comes up again I'll let you know. Like I said, it was during > the > > outtage so maybe the db went down as osmosis was opening the file for > > writing or something like that. > > > > -Jeremy > > > > > > > > _______________________________________________ > > dev mailing list > > dev@openstreetmap.org > > http://lists.openstreetmap.org/listinfo/dev > > _______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
