[Tilesathome] t at h server updates

[Christopher Schmidt]

On Fri, Nov 16, 2007 at 11:28:39AM +0100, Sebastian Spaeth wrote:
> On Thu, Nov 15, 2007 at 11:15:07PM -0500, Christopher Schmidt wrote:
> > 1. The user requesting a tileset is now recorded...
> > 2. Which let me find out that some clients were requesting a huge number
> >    of requests, which let me find out that...
> > 3. The t at h server has not been correctly handling re-requests since
> >    mid-August. This is now fixed.
> 
> thanks for fixing this. However, now you reinsert failed jobs without modifiying the date field in the queue table of the db.
> This effectively puts rerender requests at the very front of the queue, rather than reinserting them at the end. This has the unpleasant side effect that renderers who can't cope with a tile will return it ask for a new job and are likely to be handed the exact same tile they just returned as it is in the front of the queue.

I thought date was an auto-update field? Certainly my testing shows
this: When *anything* is updated in the database, the 'date' column is
upated to the current time unless explicitly set. If you watch the
"Recent REquests" page when a client is doing re-queues, you'll see them
pop up at the top of the list (meaning that their 'date' is very recent)
even if they were already in the queue.

So, I think the answer is that although I don't modify it in the sql
directory, it is still modified automatically by the SQL.

If you can confirm that this is *not* the case -- or you have seen cases
where it is not -- that's cool.

What I don't do is bump the priority down: so a client which is unable
to render a tile which is the last in its current priority will download
and requeue the tile until some other client snags it.  I can't come up
with a trivial solution for that, but we have the data to check whether
something was:

 * A re-request
 * And the same client is asking for the tile again.

If that's the case, we can tell them 'no data', and hopefully some other
client will pick it up quickly. I can implement this later today,
hopefully. 

Regards,
-- 
Christopher Schmidt
MetaCarta