My test 10.2.2 bundled cache I am trying to convert is ~ 9GB. I also notice, many files are created here that are never cleaned out when the command crashes (although I am deleting between running my processes). I know from previous experiences (when caching caches with 10.0) that there are many temp files that are created inĬ:\users\\AppData\Local\Temp that never get cleaned out properly. Even though it never gets to zero, it seems that the more space I have available when I start one of these commands, the longer it will go before it crashes. I get the error from both.įor me, I think the issue is I'm running out of temp space on my C drive. The other tool I tested to see if this would word was an attempt to export/convert it back to an exploded cache to see if I would get it to work from that format. So, although I've come at it several ways, what I'm really wanting to do is to use the "Upgrade Map Server Cache Storage Format" in the Server Tools->Caching toolbox. In this case, I'm testing 10.3 pre-release because I wanted to compare the 10.2.x bundle with the new 10.3 bundle, to see if it really was smaller. And although my error "the index was either too large or too small" is coming from a different process, my guess is it related to all the above. I'll just send this as is.with the added note that the AppData folder will be hidden on many machines by default, but it you type the path in (after you get to the user folder) you should be able to find it. Hmmm.I was going to respond with the oath and found a "recovered" comment (from who knows when) that I obviously never sent. Thus far, the only solution has been to kill the service, stop the site, and then remove the entire cache directory, restart the site, recreate both the service and the cache. During the recreate, the bundlx file is being removed but the bundle file is not, thus not allowing the tool to overwrite thebundle from the admin-defined D:/arcgistemp folder(s) on the GP server. When the error occurs, the entire cache becomes corrupt, making any other caching operations in-operable (delete cache, delete tiles, etc). All permissions for directory shares and folder and file security have been accounted for. This has occurred as of lastweek whether reading from the GIS SDE database OR from a data-store file gdb. Two servers serve as a mapCluster for map and image services, a single server in a gpCluster for caching and user-defined gp services, and a virtualized web server for the WebAdaptor. Our clustered setup consists of a network file server storing our config, security and data-stores, as well as all server and system directories. The error occures when running RECREATE_ALL_TILES or DELETE_TILES operations of the Manage Map Cache Tiles (run as a tool or script) when run from a dedicated server gp cluster machine. I am unable to either DELETE_TILES or RECREATE_ALL_TILES from an existing cache. We are experiencing brand new caching issues at 10.2.2.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |