We started to experience a problem with a clients ImageVault installation after doing an upgrade to version 4.8.219.113 of the product. Large images being stored on a network share started to cause the MediaStreamService to throw Internal Server Errors while being fetched by the website.
The ImageVault Core itself is not load balanced, but the EPiServer installation is however distributed over a couple of front servers as well as an editor machine.
We had experienced a similar issue on ImageVault 4.7 a few months back while performing load testing on the client’s public website (see ImageVault Core unable to retrieve large files during load test), and the ImageVault Core log files confirmed that the Shadow Copy Cache may be involved here as well.
ImageVault.Core.Service.MediaStreamService. WriteResponseHeadersAndGetContent - Error WriteContentToResponse, Id:'3vl1gllfd5p8b1riprai'. The file 'C:\Users\IVCoreServiceAccountUser\AppData\Local\Temp\DiskStorage\3vl1gllfd5p8b1ripraithe-image-name.jpg' already exists. System.IO.IOException: The file 'C:\Users\IVCoreServiceAccountUser\AppData\Local\Temp\DiskStorage\3vl1gllfd5p8b1ripraithe-image-name.jpg' already exists.
The C:\Users\IVCoreServiceAccountUser\AppData\Local\Temp\DiskStorage\ directory is ImageVault Core’s default Shadow Copy directory.
Disabling the shadow copying by adding <add key=”DisableShadowCopy” value=”true” /> to the ImageVault.Core.Host.exe.config file and restarting the instance’s ImageVault Core service fixes the problem; the large images becomes accessible if surfing to them. They also remain accessible after the shadow copy cache is enabled again, and the service restarted. The difference between the previous issue is that back then it didn’t work regardless of this setting.
I’ve placed a support ticket with Meriworks ImageVault support to get help resolving this issue. In the meantime we will just leave the shadow copy off as it doesn’t give us any noticeable penalty anyway.
