[OSM-dev] Osmarender not always showing latest data

Milenko 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.

-Jeremy


> -----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:
> 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 <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
> 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 at openstreetmap.org
> > http://lists.openstreetmap.org/listinfo/dev
> >






More information about the dev mailing list