Slow map loading and ChallengeHandler delay - Token vs Certificate

Question

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.

MatveiStefarov · Answer

Good news, Maps SDK 200.8.0 was just released, and it includes a fix for this issue. The workaround is not necessary any more.

MatveiStefarov · Answer

Hello Bjørnar,

I was able to reproduce the problem.  A fix will be released in a future version of the Maps SDK for .NET, but I also have a workaround that should help you now.

The timeout happens when a webmap with many inaccessible items is being loaded.  Maps SDK 200.7 added new error-detection logic for some load failures, that makes an additional network request to gather more details.  Unfortunately it keeps the original HTTP connection open while making this additional request.  Many items failing to load at the same time exhausts the connection pool and nothing can progress until one of the requests times out.  The default connections-per-server limit happens to be 6.

Fortunately this connection limit is easy to raise. Set MaxConnectionsPerServer to a higher value value when configuring Runtime:

ArcGISRuntimeEnvironment.Initialize(config => config
    .ConfigureHttp(http => http
        .UseMaxConnectionsPerServer(20)
    )
    // the rest of configuration goes here
);

Please let me know if this works for you.  I will also update this thread when a proper bugfix is released.

BjørnarSundsbø1 · Answer

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.