[OSM-dev] Osmarender not always showing latest data
milenko at king-nerd.com
Tue Dec 16 13:35:07 GMT 2008
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.
> -----Original Message-----
> From: Rowland Shaw [mailto:rowland.shaw at 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:
> 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 <milenko at king-nerd.com>:
> >> milenko at king-nerd.com wrote:
> >>> I haven't figured out how the server got out of sync with the main
> >>> yet. My best guess is that I somehow missed part of a day or a few
> >>> 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
> >>> hourly diff and then go from there.
> >> Can you let me know if this happens again? That seems odd. I
> >> 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
> >> 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
> >> 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
> > outtage so maybe the db went down as osmosis was opening the file for
> > writing or something like that.
> > -Jeremy
> > _______________________________________________
> > dev mailing list
> > dev at openstreetmap.org
> > http://lists.openstreetmap.org/listinfo/dev
More information about the dev