Latest Contributions by KevinSayer

Hi Guys, We have an application built with the ArcGIS Runtime SDK for .net that's been around for several years now with relatively few changes. We have fixed some bugs in that time and this has required us to periodically upgrade to the latest version of the SDK. Our most recent release is in fact built against version 100.9 of your SDK. Chart items from our application can be added to the map and one of the things we implemented a long time ago is visual clustering on the map surface. This occurs both when the user zooms in or out and when they toggle our clustering feature on and off. Each graphic on the map represents one of our own chart items and the graphics therefore potentially have unique images, unique text labels and a triangular symbol that points to the relevant geographic location. The way this was implemented was with graphics that each have a unique composite symbol and are dynamically added to, and removed from, a single graphics overlay. The clustering algorithm dynamically calculates the clusters and assigns these graphics to the appropriate cluster, each cluster being represented by a new graphic with its own composite symbol. These cluster symbols are essentially just a circle with a text label showing the count of graphics in the cluster but they also show selection state including a special state when only some of the cluster contents are selected on our chart. To summarize, at any point in time the graphics overlay will contain composite symbols representing individual chart items, clusters or both. The graphics and symbols for the clusters are dynamically created but the graphics and symbols for the individual chart items are created once and cached by us. Each clustering operation re-groups these cached graphics removing the overhead of their creation. What we have noticed recently (initially via our application crashing) is that there appears to be a memory leak in your unmanaged code. The problem occurs in many scenarios but the easiest way for us to reproduce it is to add say 50,000 chart items to the map and repeatedly zoom in and out or, even just repeatedly toggle clustering on and off. Both of these operations remove and re-add existing graphics to the overlay which eventually causes the applicaition to crash with an out of memory exception. There is obviously always going to be a finite number of graphics you can add before running out of memory and our application is currently 32 bit so we are constrained by the 4GB limit. We are nowhere near this limit however when the graphics are initially all created and added to the overlay. I have created and attached a simple application that demonstrates this problem. The demo application initially creates and caches 50,000 graphics with a similar symbol to those in use by our main application. It then goes on to repeatedly add and remove these graphics (on the UI thread) to the graphics overlay in the handler for a System.Windows.Forms.Timer. I have profiled both our application and this little demo app and in both cases the memory footprint continues to grow until it eventually crashes. This occurs much quicker in our application as there is obviously less memory available in that context. Analysis of the profiling results show that the .net memory seems to be pretty well behaved but the unmanaged memory just continually grows with each add/remove cycle. The demo app is pretty simple but I've tried to make it comparable to our real application and for that reason the map control is inside an ElementHost. I don't think that really makes any difference however as at some point I did try it in a pure WPF application with the same results. It might seem a little odd in places and there are definitely better ways to write this demo app in isolation, but I've just lifted code and adapted it as little as possible to demonstrate the issue. Again, the intention was to keep it as close to the real code as possible. To build it you will just need to add the Esri.ArcGISRuntime.WPF v100.9.0 package in the NuGet package manager. The graphics are all created on the first timer tick so after the map initially displays there will be sizeable delay whilst that happens. The graphics are subsequently just added and removed on alternate ticks so you can take a memory snapshot when they first appear and then another a few iterations later, or just watch the memory climb in the visual Studio Diagnostic Tools Window. I've actually profiled it in a few different tools to come to my conclusions. I would appreciate someone taking a look and either confirming my findings or letting me know if there's some other issue I've overlooked. Regards, Kevin ... View more

Hi Guys, Does anyone have an answer to these issues please, especially the crashing one? Issue 1: We have an application that uses PKI authentication with ArcGISPortal but we seem to experience an intermittent crash due to a null certificate getting into the X509CertificateCollection on the HttpClientHandler. There are 2 places where the application can intermittently crash (X509CertificateCollection.GetHashCode and x509CertificateCollection.Contains) but both cases are due to the same reason. i.e A null certificate entry in the handler's collection. I have attached images that show the call stacks for both crashes and also the certificate collection contents where you can clearly see the null certificate entry.  It's worth noting that one of the call stacks contains an ArcGISHttpClientHandler and the other just uses a standard HttpClientHandler, yet both result from calling await PortalItem.Thumbnail.ToImageSourceAsync() I have also attached a simple demonstration application but you will need a Portal instance with PKI setup to test it.  You will also need to update the hard coded portal uri and certificate thumbprint as detailed in the source file comments. The application automatically connects to a portal instance on startup using the certificate with the hard coded thumbprint.  The displayed "Portal User" is updated once connected and it then goes on to fetch a list of all the available base maps.  A thumbnail image is then fetched for each basemap and these images are each displayed on separate buttons.  The button handlers are not wired up in this application. The "Create Portal" button and the checkbox beside it can be ignored for now. Steps to reproduce: Just keep restarting the application and eventually you should get one of the two exceptions mentioned above.  If you get to the point where the images start appearing then you may as well quit and restart as the problem will not occur after that. Issue 2: We also have a use case for clearing the SSL state and reconnecting with a different client certificate.  The Esri documentation states that removing the certificate credential from the AuthenticationManager's credential collection should result in you getting challenged again on the next  request.  This does indeed seem to be the case but if you choose a different certificate the connection then fails with the following error, "Your login session has been reset. Please try again."  Trying again with the new certificate succeeds on the second attempt but having to do this twice is not a great UX. Steps to reproduce: Assuming you have more than one valid client certificate installed and they're both mapped to portal users, after the initial load succeeds, uncheck the "Use default client certificate" check box and press the "Create Portal" button.  This will attempt to create a new portal instance, prompting you to select a client certificate, at which point you should select a certificate with a different thumbprint to the hard coded one. The connection will fail and display the exception message in a dialog box.  Dismiss the dialog box and try again with the same certificate - Assuming it's a valid certificate that has been correctly mapped, It will succeed on this second attempt. I have tried to tear down the SSL connection in the Reset method but unfortunately this doesn't make any difference.  The code also uses reflection which is obviously a bit hacky but unfortunately the .net framework doesn't support this through the ServicePoint API.  Although this Reset method is called on every connection, it's definitely not the reason for the first crashing issue as that still happens with the Reset method removed. The problem was originally noticed on 100.3.0 but I've just updated it to work against 100.4.0 which was released last week.  I was hoping that might fix it but unfortunately the crash is still present. Any comments and/or workarounds would be appreciated. Regards, Kevin ... View more