[Tilesathome] either nodata or Forked render failure

[spaetz]

On Wed, Aug 27, 2008 at 09:24:25AM +0200, Florian Lohoff wrote:
> Are you actually shure that the "NoData" failures are real? I mean could
> it be that the client tries to render something in the middle of the
> Atlantic and there really IS no data?

Yes, the NoData's are unfortunately very real. Just try to retrieve a small tile of ocean with e.g.
./tilesGen --Debug=1 xy 0 0

It takes ages for the data to come back, if at all. Sometimes the API will also immediately throw Error 400 or 500, seemingly at random.

Unfortunately getting to the data is quite hard at the moment, it seems. I look forward to the moment we have a read-only database that is actually performant.

> BTW: There seems to be more fork bugs lurking around:
> 
> [#128   0% jobinit] Doing tileset (12,1086,1509) (area around 42.714724,-84.506836)
> removing job dir/home/flo/tah/tilestmp3/12_1086_1509_SsIwg

Is this the very latest version from this morning? It's running fine on my box with fork=0, fork=1 and fork=2 now.
 
> ERROR
>   The following command produced an error message:
>   "zip" -r -j /home/flo/tah/tilestmp3/uploadable/_1023945115_14266_caption_tileset.zip /home/flo/tah/tilestmp3/caption_12_1086_1509.dir > /home/flo/tah/tilestmp3/zip.stdout
>   Debug output follows:
>   |
>   | zip error: Nothing to do! (try: zip -r -j /home/flo/tah/tilestmp3/uploadable/_1023945115_14266_caption_tileset.zip . -i /home/flo/tah/tilestmp3/caption_12_1086_1509.dir)

If this were a forking error, there were no  /home/flo/tah/tilestmp3/caption_12_1086_1509.dir at all, the .dir would have been destroyed beforehand. I suspend an inkscape crash or some failure with the png optimizers which leave you with no png files in the .dir directory...

Do you still have /home/flo/tah/tilestmp3/caption_12_1086_1509.dir around? If yes, see if there are any files in there and if yes, which.

spaetz