Hi,
After upgrading to 200.7 I am experiencing that my map is taking forever to load. While a large map with manygrouplayers, subgroups and various layers on them I expect it to take a little while,. In 200.6 it is relatively smooth, but all the layers load within 4-5 seconds.
I have logged all ChallengeHandler requests, and I can that there is a big difference on how these are logged.
On version 200.6, all the 49 challenges are flooded to the output window within the span of 4 seconds.
On version 200.7, the same challenges takes a drip-drip-drip approach, and takes several minutes. Each drip is roughly 6 challenges every 100 seconds, which corresponds to the default timeout. The layers don't finish loading until all the challenges have completed, which takes 10 minutes.
I notice that there is only one challenge for Token, and the remaining 48 challenges are for Certification, which I do not understand. I've updated my ChallengeHandler to use the default handler when the request is for certificate, though having the user confirm that dialog 49 times is not particularly user friendly, though I am trying to to figure out how to accept it without user interaction
Questions:
1. Why is the loading/authentication so incredibly slow and come in bursts on 200.7? It is obviously an issue introduced in the latest version
2. Is there something that I can do to work around the slow map loading? I've not yet done anything with interceptors or ArcGISHttpMessageHandler as described here, as it hoped it was automatically wired up, but I'll investigate this.
I've tested with an custom interceptor to log any timeouts, I've narrowed down some requests. ArcGISHttpMessageHandler appears to be automatically introduced so no magic there needed.
internal class CustomMapsInterceptor : IHttpMessageInterceptor
{
public async Task<HttpResponseMessage> SendAsync(HttpMessageInvoker invoker, HttpRequestMessage message, CancellationToken cancellationToken)
{
var stopwatch = System.Diagnostics.Stopwatch.StartNew();
try
{
var response = await invoker.SendAsync(message, cancellationToken);
stopwatch.Stop();
Log.Logger.Information("Request to {Url} completed in {Duration}ms", message.RequestUri, stopwatch.ElapsedMilliseconds);
return response;
}
catch (TaskCanceledException ex) when (!cancellationToken.IsCancellationRequested)
{
stopwatch.Stop();
Trace.WriteLine($"Request to {message.RequestUri} timed out after {stopwatch.Elapsed.TotalSeconds}s");
throw new TimeoutException($"The request to {message.RequestUri} timed out.", ex);
}
catch (Exception)
{
stopwatch.Stop();
Trace.WriteLine($"Request to {message.RequestUri} failed after {stopwatch.Elapsed.TotalSeconds}s");
throw;
}
}
}
This is the log information I get. There is a timeout for data?f=json of 100 seconds, and two seconds after that it attempts to challenge.
Request to https://my.portal.no/portal/sharing/rest/content/items/1b64d928f5eb41feb8d670aecdd13db1/data?f=json failed after 100,6283715 seconds
Challenged for Certificate for https://my.portal.no/portal/sharing/rest/content/items/1b64d928f5eb41feb8d670aecdd13db1/data 102,8218895 seconds after first Credential Challenge
It appears that we might have identified the scenario to recreate the issue, though no sample application. Starting out with a description:
The loaded map is a WebMap. The map contains many feature layers that have been added as items rather than direct URI to the service. The webmap is shared with the user and works with the token, though the map items (feature layers) are not shared with the same user.
When loading the map we get a token challenge for the first layer which is successful, but the token under the same path does not authenticate against the unshared layers which leads to the certificate challenge.
The map loads «fine» and all layers enter loaded state when there are less than 6 feature layers without authentication, but the map data for the «failed» layers does not render (or lead to LoadStatus.Failed). Adding more than 6 layers than leads to 100 second timeouts and the user having to wait 10 minutes for all the timeouts to be reached for the 48 layers without permission and load state set to !Loading and !Failed.
Sharing the items with the correct user appears to fix the issue, though this seems to be an issue introduced in 200.7.