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; } } }

The ???red color??? and ???number??? with the service name,

JamalNUMAN

The ???red color??? and ???number??? with the service name,

I particular cases, as an mxd file is published, red mark and ???number??? at the end of the name are created as shown in the screenshot below:

[ATTACH=CONFIG]30354[/ATTACH]

What might this indicate for?

Thank you

Best

Jamal

Clip_6.jpg

Storymap_Title.png

Finde mehr Beiträge mit dem Tag

Accepted answers

All comments

AntGiles

Jamal,

The red square is showing you that the service is stopped. The numbers at the end are a date/time, I have seen this happen when you republish over an existing cached service and choose the option to keep the cache.

Regards

Anthony

JonathanQuinn

I can't reproduce this at 10.2.1; if you republish a service and choose the option to update cache automatically, it'll recreate tiles in the same cache folder. If you choose the option to update cache manually, it should only create a new folder within the cache directory with the service name and timestamp. This behavior is described here.

At 10.2, the options were a bit different. If you overwrite a service you have two options through the publishing wizard to keep the cache or overwrite the cache. Unchecking the option to keep the cache will create a new folder within the cache directory with the service name and timestamp, per the information here.

Any behavior other than that, for example a new service is created with the timestamp appended to it when overwriting, could be a bug.

AntGiles

Jonathan,

I have experienced the duplicate service with a time stamp the same as Jamal, we are using 10.1. It's not consistent so like you say it may be a bug.

Regards

Anthony

JonathanQuinn

This looks like it's already logged as a bug. The version found states 10.2, so I can see the process showing similar behavior at 10.1 SP1. I imagine if I tried a couple more times I could reproduce it at 10.2.1 then.

JamalNUMAN

This looks like it's already logged as a bug. The version found states 10.2, so I can see the process showing similar behavior at 10.1 SP1. I imagine if I tried a couple more times I could reproduce it at 10.2.1 then.

Thanks Anthony and Jonathan,

If the service is cached, this this problem appears in case the service is republished with the option �??overwrite an existing service�?�

If the service is not cached, this problem never appears

Does this problem persists to exist even in 10.2.1?

RoyceSimpson

I can't reproduce this at 10.2.1; if you republish a service and choose the option to update cache automatically, it'll recreate tiles in the same cache folder. If you choose the option to update cache manually, it should only create a new folder within the cache directory with the service name and timestamp. This behavior is described here.

At 10.2, the options were a bit different. If you overwrite a service you have two options through the publishing wizard to keep the cache or overwrite the cache. Unchecking the option to keep the cache will create a new folder within the cache directory with the service name and timestamp, per the information here.

Any behavior other than that, for example a new service is created with the timestamp appended to it when overwriting, could be a bug.

Why was this changed from 10.1 to 10.2.x? At 10.1 if you overwrite a cached map service, you had the option to keep the existing cache (very beneficial for us). At 10.2.x, that option is no longer available so when you overwrite, a new cache folder is made and you either need to recreate the cache on the spot or copy the cache from the timestamped cache folder into the newly created cache folder. We run our cache updates every 2 weeks and each one takes 14+ hours. There are many cases where we want to republish an mxd but keep the existing cache and just wait until our biweekly caching process redoes the cache after hours.

Is there any way at 10.2.x to specify during the republishing process to keep the existing cache in place?

JonathanQuinn

The option to keep an existing cache should be added back at 10.3.

RoyceSimpson

The option to keep an existing cache should be added back at 10.3.

Ok, good to know. Thanks for the info.

Nimm an der Diskussion teil

Angemeldete Mitglieder können Beiträge verfassen, Updates folgen und mehr. Neu hier? Registriere ein kostenloses Konto.

Schnellzugriffe

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.