[Tilesathome] Dissappearing tiles.

[Dirk-Lüder Kreie]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

spaetz schrieb:
>>> They are not being thrown away, they will still be uploaded once they get
>>> a slot in the upload queue.
>> Sloppy language on my part, sorry.
> 

>> Technically you are correct, but in reality, what is happening is
>> that 1 tile request is being processed in full by up to 6 different
>> clients,
> 
> Yes, that could happen, but only something like 30 hours after the
> first job has been handed out. These 30 hours would only apply if all
> our job queues were empty (in which case some redundancy wouldn't
> hurt). If queues are longer (as is the case now) a failed job will
> effectively be requeued, so it will take much longer until a rerender
> request is reissued. And if the upload happens while the rerender
> request is still in the pending queue it will be deleted.
> 
> So yes, while some redundancy can occur, I think it is not as bad, as
> a rerender request will sit and wait in our queue for quite some
> time, giving the uploaded tile some more time.

As far as I understand the upload will then remove the "redundant"
request from the queue so it wouldn't get handed out a second time anyway?

>> Such a waste of processing power. Perhaps at times like these, it
>> would be a good idea to throttle back the number of requests being
>> given out to try and bring the upload queue under control?
> 
> Would be nice, and I did implement this with a "maximum active number
> of concurrent jobs" rate limiting. However it miserably failed as
> many requests fail to render and - as we don't have good failure
> feedback mechanisms - effectively clogged up the active job slots
> with failed jobs. This lead us to only have a handful of actually
> rendering clients at any one time. In order to improve this, we would
> need better failure feedback from clients to the server.

There is feedback, just not in a good form. Change
"putRequestBackToServer()" in the client and create an appropriate
serverside part to act on the reports.

- --

Dirk-Lüder "Deelkar" Kreie
Bremen - 53.0952°N 8.8652°E

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHL5hVFUbODdpRVDwRAlIvAJ0V93EPWYnJ+QtWUOunGymsV9HRUgCfea01
D0CM1bkncAZ/79e0sJM9zW4=
=mJfy
-----END PGP SIGNATURE-----