Hmm. Afaik, it should. As a shot in the dark - are you sure that it's not some downstream (client or asp.net) caching to blame? I would recommend first of all to check it by monitoring requests-responses with some http debugger like Fiddler.
No I've checked and the files in Cached/ don't get updated at all - their file date/time is still the same, even though the file date/time on the original is newer.
ImageGen *should* notice the change in the source image if the filesize or datestamp is different. What version of ImageGen are you running (use the imagegen.ashx?version querystring to find out)? Perhaps there's a bug.
As potential workarounds to get you going again...
If you temporarily use the &nocache=true querystring on one of your images that will force ImageGen to recreate any already-cached image. Bad for performance but a way to force a cache refresh. Or you could delete the cached folder associated with the image you've updated and that will force ImageGen to regenerate images.
Can you show me the details of the "Thumb" class and the "Default" class from your imagegen.config file? That'll be helpful to understand exactly what ImageGen is attempting to do.
It could sound like a stupid question of mine, but do you mean that your src="" in the img tag is just hardcoded like you've just written? Actually if you upload a new image file onto the same media item the name of uploaded file inside a /media/NNN/ folder can be different from that it was before.
A quick few tests and I can confirm I've found a bug... but I don't think it's causing what you're seeing. I'll do more research to be sure though, and I'd still like to see your Thumbs and Default class settings.
What I have also found, is that if one reloads the browser with a shift-F5 to force the browser to get new images from the server rather than relying on its builtin cache you should get the updated image from ImageGen. In other words, if you get a 200 response from ImageGen rather than a 304 response you should get the correct image.
Actually, I guess that means I have found two bugs... the 304 response shouldn't happen if the source file has changed.
Thanks. The CachingTimeSpan is important and one of the things I was looking for. It means the browser won't even ask ImageGen for a new image until 3600 seconds (1hr) has expired. With no request, ImageGen won't update its cache. So that setting can hide/frustrate the issue and debugging.
Best bet is to use firebug or an 'inspector' to be sure you're getting 200 responses from ImageGen rather than using the builtin browser cache or getting a 304 from ImageGen. With a 200 response you can be sure that ImageGen got the request for an image and sent back what it thought was the appropriate image.
I'm making progress. I've found and fixed the first of three issues that are making this not work properly. The second issue is a tough one to resolve without taking a big performance penalty so I'm still pondering how best to handle it. After that I'm pretty sure the third issue will be trivial and we'll have a solution for you to test.
I might have a solution for you Friday but it might also be next week, so I'm letting you know so you can plan accordingly for your site launch.
Again, thanks for your help in identifying this and working with me to get a solution. I'll keep you posted.
ImageGen caching even if file replaced
We're stuck by what seems like a really obvious issue. Can anybody help?
Wouldn't ImageGen.aspx at least check the file date of the file it's caching to ensure the cache is rebuilt in this case?
Thanks!
- Brian
Hmm. Afaik, it should. As a shot in the dark - are you sure that it's not some downstream (client or asp.net) caching to blame? I would recommend first of all to check it by monitoring requests-responses with some http debugger like Fiddler.
Hi Rodion,
No I've checked and the files in Cached/ don't get updated at all - their file date/time is still the same, even though the file date/time on the original is newer.
- Brian
Well. How do you build your <img> tag to display image?
Hi, Brian,
ImageGen *should* notice the change in the source image if the filesize or datestamp is different. What version of ImageGen are you running (use the imagegen.ashx?version querystring to find out)? Perhaps there's a bug.
As potential workarounds to get you going again...
If you temporarily use the &nocache=true querystring on one of your images that will force ImageGen to recreate any already-cached image. Bad for performance but a way to force a cache refresh. Or you could delete the cached folder associated with the image you've updated and that will force ImageGen to regenerate images.
cheers,
doug.
Hi Doug and Rodion,
We're using "ImageGen Professional version 2.5.2.17053". (With professional featured enabled for our domain.
Currently we're using Windows Search on the VPS and deleting all the folders called Cached in the media folder - which obviously works but is a pain!
Here's an example of how we call ImageGen.aspx:
<img src="/ImageGen.ashx?image=/media/158688/farinet_identity_apresski_POS_lowres.png&height=170&width=170&crop=resize" class="Thumb">
Thanks!
- Brian
Thanks, Brian.
Can you show me the details of the "Thumb" class and the "Default" class from your imagegen.config file? That'll be helpful to understand exactly what ImageGen is attempting to do.
cheers,
doug.
It could sound like a stupid question of mine, but do you mean that your src="" in the img tag is just hardcoded like you've just written? Actually if you upload a new image file onto the same media item the name of uploaded file inside a /media/NNN/ folder can be different from that it was before.
@Rodion - good point!
@Brian -
A quick few tests and I can confirm I've found a bug... but I don't think it's causing what you're seeing. I'll do more research to be sure though, and I'd still like to see your Thumbs and Default class settings.
What I have also found, is that if one reloads the browser with a shift-F5 to force the browser to get new images from the server rather than relying on its builtin cache you should get the updated image from ImageGen. In other words, if you get a 200 response from ImageGen rather than a 304 response you should get the correct image.
Actually, I guess that means I have found two bugs... the 304 response shouldn't happen if the source file has changed.
Look forward to hearing from you.
cheers,
doug.
Rodion - No, I have some Razor code that figures out what media to display and dynamically reads the correct filename.
Doug - Thanks for your quick response, very impressive!
Just FYI that the "class" is CSS - it's not sent to ImageGen. I've tried hitting just the URL, not from HTML, and get the same issue.
I don't think we've changed the config file from the defaults - ours has:
<Class Name="default" OverridesQueryString="true">
<AllowUpsizing>false</AllowUpsizing>
<MaxHeight>800</MaxHeight>
<MaxWidth>987</MaxWidth>
</Class>
<Class Name="Thumbnail" OverridesQueryString="true">
<InheritFromClass>default</InheritFromClass>
<Width>200</Width>
<Height>200</Height>
</Class>
I noticed that before we had an element <CachingTimeSpan>3600</CachingTimeSpan>. I took that off and tried again and still same issue.
I'll email you some more specific screen captures now to see if that helps...
Thanks!
- Brian
Thanks. The CachingTimeSpan is important and one of the things I was looking for. It means the browser won't even ask ImageGen for a new image until 3600 seconds (1hr) has expired. With no request, ImageGen won't update its cache. So that setting can hide/frustrate the issue and debugging.
Best bet is to use firebug or an 'inspector' to be sure you're getting 200 responses from ImageGen rather than using the builtin browser cache or getting a 304 from ImageGen. With a 200 response you can be sure that ImageGen got the request for an image and sent back what it thought was the appropriate image.
Looking forward to your email.
cheers,
doug.
Perhaps, if there's in fact a bug with caching a quick temporary workaround would be handling Media.AfterSave event and removing cache files on it.
Hi Doug,
So it looks like to me, ImageGen is returning "304 Not Modified" even though the image is actually modified...
Here's what I did:
If I clear my browser cache, then I get 200 and it returns the correct, new image.
I'm getting a bit lost in the details, but it seems to me that if you can release an updated component that fixes the 304 bug, then we're golden.
Thanks,
- Brian
Rodion,
That's a nice idea for a work around. If Doug isn't able to wrap up the bug fix before our site launch on Monday maybe I'll go ahead and do that.
Thanks again to both of you!
Regards,
- Brian
Rodion,
That's a nice idea for a work around. If Doug isn't able to wrap up the bug fix before our site launch on Monday maybe I'll go ahead and do that.
Thanks again to both of you!
Regards,
- Brian
Hi, Brian,
I'm making progress. I've found and fixed the first of three issues that are making this not work properly. The second issue is a tough one to resolve without taking a big performance penalty so I'm still pondering how best to handle it. After that I'm pretty sure the third issue will be trivial and we'll have a solution for you to test.
I might have a solution for you Friday but it might also be next week, so I'm letting you know so you can plan accordingly for your site launch.
Again, thanks for your help in identifying this and working with me to get a solution. I'll keep you posted.
cheers,
doug.
is working on a reply...