nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Overwrite Existing Service Keep Existing Map Cache 10.2.1

KenCarrier

I am not sure who decided to change how services get overwritten in 10.2.1 but I do not think this new method makes things any better. It actually adds extra steps if overwriting a service with an existing cache.

Often times when building a map document for a caching operation you use group layers to help symbolize data at different scales. Although after the cache has been created you wish to simply your rest endpoint by removing the group layer and only including the layers you wish to query or create pop-ups/identify. This makes it easier for developers who are using your services to write applications against.

In 10.1 SP1 we had the capability to overwrite an existing service with the option to "KEEP EXISTING MAP CACHE. Now when you overwrite a service at 10.2.1 it creates a new folder structure in your REST endpoint and a new cache. This seems counterproductive to me and I truly do not understand the logic, although if someone can explain how this makes things easier I would be willing to listen.

I would like to request that the option still be given to overwrite an existing map service with the ability to keep the existing cache. As it is now I have to manually copy the cache from one location to another, this extra step seems like it could be avoided if Esri would give us the method back that existed in 10.1 SP1.

Vind meer berichten getagd met

Closed

Status: Closed

Reacties

jill_es

There have been many advancements in caching since this was originally logged. If you have any further ideas for us, please let us know!

ericmahaffey2

I sure do hope this issue gets resolved. I just blew away 10 hours worth of caching time because I wiped out the new service that automatically gets generated with a timestamp at the end of it. According to the 10.1 documentation:
"If your service has a map cache, you'll also be asked if you want to keep the cache. If you check Keep existing map cache, the cache is untouched by the overwrite process and you are responsible for running an update using the caching tools. The update will overwrite the existing tiles in your cache. This workflow is sufficient for most deployments.

If you uncheck the option of keeping the cache, all existing tiles are disassociated from your service and become associated with an additional automatically generated service named <service>_<timestamp>. This service exists so that you can delete the old cache at a time that is convenient for you, since deleting a cache can be a time-consuming process.

When you perform an overwrite with this option unchecked, the caching tools immediately begin building a new set of tiles for your original service. You can cancel this job and run the caching tools yourself if you want to build the cache manually. You can enable on-demand caching if you are concerned about clients experiencing downtime."

BTW, I'm not even being prompted to keep my existing cache anymore, the application just defaults to an "uncheck" everytime.

ESRI please give use the control that we used to have over the services back in 10.0. We shouldn't have to bounce all over the place to make updates to our services. Things were soooooo much simpler before.

KenCarrier

In working with Esri support this has in some sense been a known issue since 10.2. I will refer those who are reading this to what was sent to me by Esri support.

"#NIM096854 ArcGIS Server 10.2 will create a duplicate service when we overwrite an existing cached map service even when we choose "Update cache manually" option. ]".

While this does not entirely address the issue I am referring too I did also learn that the ability to keep an existing cache when overwriting an existing map service was mistakenly taken out from all releases after 10.1 SP1 and is supposed to be coming back with 10.3 release scheduled sometime around Esri UC 2014.

If all of the above is true and I have no reason to believe it is not, I want to thank Esri for correcting the mistake and giving us this functionality back, I myself appreciate it. Thank you!

Doe mee aan het gesprek

Meld je aan om te posten, content te volgen en meer. Nieuw hier? Registreer gratis.