Problem uploading replacement photo

[nikos]

While trying to upload a replacement photo in place of an already

existing submission, I get the following error: "The requested URL

cannot be accessed due to a system error on this server"

 

Maybe it's a temporary issue due to the ongoing changes to the site.

I thought I'd mention it just in case Brian isn't aware of the

problem.

[nikos]

Tried again a little later and it was fixed.

[nikos]

Ooops.. now there's another problem: while the thumbnails on the community page appear correct, the folder view contains thumbnails of the older versions, stretched out to the dimensions of what the new version's thumbnail should have. I purged my cache and did a hard reload, and the problem persists. Either it's some bug on photo.net's side delivering an old version of the thumbnail, or there's some intermediate cache somewhere in my provider that keeps sending me the wrong file.

[mottershead]

This is because thumbs.photo.net, which is the caching server for thumbnails, still has the older version, while the dimensions specified in the HTML are coming from the database, which has the new dimensions. It takes a while for thumbs.photo.net to find out that the old version should be replaced.

[nikos]

A dozen hours or so must have passed since I replaced all my photos with new versions and now only one of my folders features new thumbnails, while the rest still look crap. If thumbs.photo.net refreshes periodically I would expect them all to pretty much be refreshed in the same time. (I did all submissions within a quarter of an hour) Maybe you have a different mechanism at work that's less obvious. In any case, while it's acceptable to have a couple of hours delay for something like this, I don't see why it takes almost a day to happen. I don't want to be grumpy or something. Some of these photos have been sitting there for years, so they can wait for a day, but unless there's some serious technical reason for the delay, tuning for quicker refreshes might be a good idea.

[mottershead]

It is a squid server, and I don't know how long it keeps its cache copy. I will have to check. Caching the thumbnails is a huge performance gain and is one of the main reasons that we have gone from having chronic performance to problems to having good performance. So I'd sooner turn off the ability to update the image for a photo than invalidate the cached thumbnails very frequently.

[nikos]

Ok, so then probably the problem is me. I had too much time on my hands yesterday and checked my portfolio every 3-4 hours to see if the thumbs were updated. This was probably causing squid to redump these thumbs into the recently accessed queue, thus retaining them as opposed to letting them expire and later re-load them.

[nikos]

I am aware of this feature of IE and already tries it. It doesn't work. I am not sure it works exactly as you describe. For sure, holding the shift button while pressing reload causes IE to disregard its own cache and any proxy cache used in the proxy setting on the browser. (for example a cache server on your ISP) But I'm not sure if it's meant to have an effect on a server-side cache. Server-side caches are considered internal elements of a web serving infrastructure and their decisions to retrieve data from the master store or the cache are not meant to be controlled or influenced by the client. So, a squid that is not configured as a proxy cache for incoming traffic, but rather as a serving cache for outgoing traffic should normally execute its cachnig policy regardless of no-cache headers sent by the browser. But then again, this is just my hypothesis, I am not sure about any standards regulating these exchanges.