AnsweredAssumed Answered


Question asked by j.buchtaesri-de-esridist Employee on Jul 15, 2015
Latest reply on Jul 24, 2015 by akajanus-esristaff

Currently, I'm testing ExportTileCacheTask.EstimateTileCacheAsync(..). While it's pretty easy to get started with this API, I'm having a hard time to get it really stable and user-friendly. I'm not sure if I'm using it wrong or if anything should be improved behind the scenes.


No detail information, if number of tiles > 100.000

Querying the Sampleserver (World_Street_Map (MapServer)) for the whole world with LOD == 9 results in an Exception with the message "Export tile operation failed".

If I use the REST API, I do find the reason why, it clearly states: "ERROR 001564: Requested tile count(262144) exceeds the maximum allowed number of tiles(100000) to be exported for service World_Street_Map:MapServer".

The only way to get access to this information is to parse all messages of ExportTileCacheJob.Messages after execution finished... which brings to the next problem:


await exportTilesTask.EstimateTileCacheSizeAsync(...) immediately returns

The method call immediately returns to the execution of the method. At this point, the returned job contains close to zero information. I think the method immediately returns because of "submit and query" pattern implemented at server side. The callback "(result, ex)" does not provide me with job information, so right now I extended my method with a "TaskCompletionSource":

var taskCompletionSource = new TaskCompletionSource<EstimateTileCacheSizeResult>();
var job = await exportTilesTask.EstimateTileCacheSizeAsync(options,
     (result, ex) =>
                        if (ex == null) { taskCompletionSource.SetResult(result); }
                        else { taskCompletionSource.SetException(ex); }
                    }, .....);
await taskCompletionSource.Task;
// job finished with all information here

This works (for me), but I really don't know if that's a correct / good pattern. It seems like a much of overhead to simply get an estimation. Is this pattern correct? Should it be integrated into the SDK itself? Is there a simpler way to get finished job information?


Randomly getting HTTP 500 Errors

I do get random 500 errors, raising an exception and exiting the estimation. I'm not absolutely sure, but I think I do get those errors more often, the smaller I set checkInterval argument.

Maybe, this is what happens behind the scenes:

  1. Runtime SDK asks server to start the job
  2. Server returns the job id, while still starting the job
  3. Runtime SDK asks (kind of) immediately for the job status
  4. Server is still starting the job and replies with 500

Taking the job id of the error message and looking at the state with the Web Browser, the job states "succeeded", so I guess it must be some kind of timing problem (see step 3).

Any ideas on that?


Kind Regards

Jens Buchta