350020 - Item previews/screenshots page gets cached for a rather long period of time

Status: RESOLVED FIXED

(addons.mozilla.org Graveyard :: Developer Pages, defect)

Description

[Nickolay_Ponomarev]

I uploaded a preview image for an extension. Since it got screwed up (AMO doesn't understand PNG transparency), I deleted it and uploaded a fixed version. That didn't help, so (after randomly clicking through the web interface) I first uploaded the image two times, then deleted the first of them. Still, for some time (half an hour, maybe more?) the public pages still showed the old version of the image (the URL was https://addons.mozilla.org/images/previews/infolister-1.jpg). After a while the URL changed to ...infolister-2.jpg and the public pages started showing the correct image.

The above text does not contain steps to reproduce and since I'm typing this from memory, some details may be wrong.

Reproducible: Didn't try.

Comment 1

[David Snyder]

Attachment: Screenshot of the _incorrect_ preview image

This is screenshot of the Editprefs previews page showing the previous, and previously deleted, preview of Editprefs 0.3.  The other attachment, editprefs-0.3.jpg, is the preview which _should_ be displayed.

Comment 2

[David Snyder]

Attachment: The _correct_ editpref preview image

This is the _correct_ preview image I have been trying to add to the Editprefs page on the addons page.  However, even after repeated attempts to delete and upload this image, the original and incorrect image still shows up (see 'Screenshot of the _incorrect_ preview image' attachment).

Comment 3

[David Snyder]

I would like to second this bug (if bug it is).  I have attempted, numerous times, to delete and update the image to be used for the Editprefs addon.  The original image I used (see 'Screenshot of the _incorrect_ preview image' attachement) still hangs around after I have deleted it and uploaded the _correct_ image (see 'The _correct_ editpref preview image' attachment).  So what gives?

Comment 4

[Michael Morgan [:morgamic]]

IT: What are the settings for /images and /css in the cache?  Is there an unnecessarily long timeout for these directories?  What is the schedule for syncing /previews?

Comment 5

[matthew zeier [:mrz]]

(In reply to comment #4)
> IT: What are the settings for /images and /css in the cache?  Is there an
> unnecessarily long timeout for these directories?  What is the schedule for
> syncing /previews?

Whatever the default cache headers are.  Do you have a sample URL?  The infolister-1.jpg below returns a 404 so I can't check.

Comment 6

[Michael Morgan [:morgamic]]

This is an example:
https://addons.mozilla.org/images/previews/infolister-2.jpg

Comment 7

[matthew zeier [:mrz]]

I ran this right after I saw your update - 244 seconds left before it's expired.   Take that plus Request Time and you should get close to total time.

Does this help any? 

> sh cache object -url /images/previews/infolister-1.jpg -host addons.mozilla.org -port 443
        Integrated cache object statistics:
        Response size: 570 bytes
        Response header size: 255 bytes
        Response status code: 404
        ETag: KXNMGICECJUWMNNUZY
        Last-Modified: NONE
        Cache-control: NONE
        Date: Wed, 27 Sep 2006 15:33:27 GMT
        Contentgroup: DEFAULT
        Complex match: NO
        URL: /images/previews/infolister-1.jpg
        Host: addons.mozilla.org
        Host port: 443
        Destination IP: 63.245.209.31
        Destination port: 443
        Request time: 86 secs ago
        Response time: started arriving 86 secs ago
        Age: 356 secs
        Expiry: 244 secs left to expiry
        Prefetch: 223 secs left to prefetch
        Current readers: 0
        Current misses: 0
        Hits: 2
        Misses: 2
        Content is gzip compressed: NO
        Content is deflate compressed: NO
        HTTP version in response: 1.1
        Weak ETag present in response: NO
        Negative marker cell: NO
        Auto poll every time: NO
        NetScaler ETag inserted in response: YES
        Full response present in cache: YES
        Destination IP verified by DNS: NO
        Stored through a cache forward proxy: NO
        Delta basefile: NO
        Waiting for minhits: NO
        Minhit count: 0
        HTTP request method: GET
 Done
> 

Comment 8

[matthew zeier [:mrz]]

fyi, after the expire period, the object shows:

        Expiry: Already expired
        Prefetch: period passed

It'll take another request to that URL before it checks the object.  Otherwise it'll be removed from the cache.

Comment 9

[Justin Scott [:fligtar]]

Remora stores previews in the database and is an overall better system for previews.