Hi Rebecca - I have ye to be able successfully update cache storage format to combined bundle type at any release. For us though it's not really that big a deal as I just go ahead and delete the old cache and create new....
David
We ultimately found that because we use (DFSR) distributed file system replication on cached images between tiles that there was some contention in the replication process causing problems. After disabling the replication process from one GIS server to the other for cached images we stopped getting errors.
Greetings all, Did anyone find out about this issue at UC?
A small update: The Recreate_All_Tiles option worked again last week (repeatedly using my python IDLE) on our stand-alone development server, but continues to fail with the same frequency and 'error moving bundle file' error in our distributed three-machine, 2 cluster production environment where our shares, directories and stores are stored on our 1Gig Lan connected file server. It would be really, really great if ESRI could comment.
David
Sorry to re-start this thread, but are there any updates on this?
I'm having near-identical issues to the OP with a very similar set up.
A 1st cache of a service works. Any subsequent caching, whether it be the full extent of the service or a number of smaller AOI's within the service leaves behind some blank spaces and some areas where a cache only exists at some scales.
I will raise a ticket with ESRI today, but was wondering if anybody had received a response/workaround/fix to this as I'm aware that a number of you had tickets in with ESRI.
Many thanks
Dan
I have a ticket with ESRI Sweden, they have been able to reproduce this error but have no solution yet.
Meanwhile I've been testing to use the EXPLODED Storage Format to get rid of the bundle-files and see if some of all the png-images gets locked as well, so far they have not.
I only have a couple of cached services that are updated regularly, I will publish them with EXPLODED storage format until I hear of another solution/workaround for the COMPACT storage format.
Thanks Matt, interesing result regarding the Exploded v Compact.
I too am working with Jon out of Redlands to get this solved. We ran some I/O tests yesterday using IOzone and thus far have determined that throughput does not seem to be the culprit. We will be running a ProcMon test later today and I will post the results