If you’re in a situation where you can shut down the app pool or W3CSVC servicing each of your WFEs, clear out the file system, and then restart the app pool or service, you should be fine. If you have multiple WFEs, each one can be cleared in this fashion one at a time; there are no depedencies between BLOB caches on WFEs.

If your environment can’t tolerate any downtime, I would strongly suggest checking out the farm-level BLOB cache flushing solution I put together (http://blobcachefarmflush.codeplex.com). I created it specifically to deal with high traffic, can’t-be-brought-down environments where the cache occasionally needed a flush due to unusual corruption situations. If you install that solution, you’ll be able to safely flush the BLOB cache for the Web application housing your site collection. The solution is really easy to use, and the flush will take place across all WFEs and extended zones.

The problem with the built-in flush mechanism (exposed through the site collection administration settings) is that the flush only happens for the server that receives the postback, and the flush only occurs for the zone (IIS site) you are working through. If you have a Web application that has been extended to more than one zone and/or more than one WFE, it’s difficult to get the built-in flushing mechanism to work for you.

If you want a bit more background on what’s happening with the flush, check out another post of mine: http://sharepointinterface.com/2009/06/18/we-drift-deeper-into-the-sound-as-the-flush-comes/

Good luck!

So, having cleared the file system incorrectly and clearing the disk cache not working, what would you recommend as a solution to get this working?

Whether or not this is “better” sort of depends on your situation. If you switch the BLOB cache to a completely new directory, it means that every cacheable asset is going to have to be re-fetched from the content databases housing them to populate the new BLOB cache. If you aren’t caching a lot of content on the WFEs, then this probably isn’t a big deal.

If you’ve got gigabytes of data that are being BLOB cached, though, re-fetching all of that content is going to put a strain (albeit a brief one) on your infrastructure. In this scenario, a targeted clean-up of a single Web application zone in the existing BLOB cache will be less invasive — assuming you have more than just the target Web application zone’s content in your BLOB cache, of course.

You’re absolutely right, though, in that there is more than one way to skin this cat; the approach I presented is not the only way. More than anything, I simply wanted to share the possible adverse side effects of clearing the file system without taking precautions.

Thanks for the feedback!

If a refresh of the page or clearing the client-side cache of images fixes the issue you’re encountering, then chances are that there is no server-side fix that is going to address the behavior you’re seeing. If the MOSS BLOB cache is involved (something you’ll have to verify), then I’m guessing that the web.config entry for the element on the web application in question specifies a max-age attribute value.

When the max-age attribute is specified, images and other BLOB resources that are served up to clients are passed back to the browser with client cacheability headers. In essence, the client will hold onto such images and resources until the amount of time specified by the max-age attribute has elapsed. Only after that amount of time has elapsed will the browser once again begin requesting the images or resources from the WFE. This is why a client-side solution, such as forcing a re-fetch or clearing the browser cache, is the only one that will actually get the browser to re-request the objects in question.

It’s been a couple of days since you submitted your comment. It’s common for the max-age attribute to be set to something like 12 hours. Your situation may even be fixed by now. If it’s not, and the max-age attribute is causing client-side caching, you should be able to use the value of the attribute to determine when things will clear up for you. The max-age attribute specifies a client-side caching duration in seconds, so divide the value by 3600 to determine how many hours objects will remain cached on client browsers.

Again, my hypothesis is entirely dependent on BLOB caching being enabled and a max-age attribute being set. If either of these aren’t in-play, then what I’m proposing isn’t what’s happening.

Good luck!

After installing Service pack2, the images in people search results are appearing to be elongated and when we refresh or if we clear cache in browser only then it becomes normal.. may i kno the reason and solution as we cant remove cache on each users machine if users are n numbers..
Please help..