ThinkGeo.com    |     Documentation    |     Premium Support

WmsRasterLayer - MapSuite Unhandled Exception

MapSuite Team,

I continue to encounter Unhandled MapSuite exceptions with WmsRasterLayer.

This is the scenario…

  1. Wms Server running on its own machine in a local network under IIS.
    2… Wms Client running on another machine within the local network.
  2. Wms Client requests layer to be displayed.
  3. Wms Client displaying layer and panning/zooming works great.
  4. On the server machine under Control Panel Disable the network to simulate a loss of network connectivity.
  5. Wms Client panning encounters an Unhandled exception within MapSuite.

The Wms Client has set the Drawing & Drawn events, which do not get invoked.

The Wms Client has tried both–>
DrawingExceptionMode = DrawingExceptionMode.DrawException
DrawingExceptionMode = DrawingExceptionMode.ThrowException

The exception is neither drawn nor thrown.

Attached are two text files that show the entries in the Windows Event Log from the exceptions in the two above cases.

If the Wms Client attempts to open the layer at the time the server machine is off the network the Layer Open() encounters an exception and is caught by the application, which is acceptable. The message from the exception is:
Unable to connect to the remote server

I’m current with all the V10 and beta packages.

Thanks,
Dennis
MapSuiteWmsExceptionNoNetworkAccessThrowException.txt (2.4 KB)MapSuiteWmsExceptionNoNetworkAccessDrawException.txt (3.4 KB)

Hi Dennis,

It looks the “Unable to connect to the remote server” problem caused many different exception.

Could you please provide us your render code so we can build a sample based on that and can reproduce this exception?

And I think maybe you can try to modify the code, add some custom code before you render the WMSLayer to test whether the internet status of your clients is OK, as below is some code I think maybe helpful.

        bool PingOK = false;
        using (System.Net.NetworkInformation.Ping PingSender = new System.Net.NetworkInformation.Ping())
        {
            PingOptions Options = new PingOptions();
            Options.DontFragment = true;
            string Data = "test";
            byte[] DataBuffer = Encoding.ASCII.GetBytes(Data);
            PingReply Reply = PingSender.Send(Address, 1000, DataBuffer, Options);
            if (Reply.Status == IPStatus.Success)  
               PingOK = true;
        }

And you can also implement that by HttpWebRequest, it’s just a refer code, you should want to modify your code follow your scenario.

Regards,

Ethan

hi Ethan,

The “Unable to connect to the remote server” was not the cause of the exceptions in the text files from my post of yesterday. This exception is caught in my application as a result of doing an Open() on the layer when the server is not available. So this is good.

The Unhandled exceptions occur after the layer has been successfully opened and after the server is no longer available and the user attempts a pan/zoom.

I don’t feel that a ‘polled’ approach to test if a server is available is a workable solution to this issue. The application could still enter this Unhandled exception between checks to see if the server is still available.

Based on your previous suggestion from another post I added code to my application to set a timer in the SendingWebRequest, but that does not work even though it is implemented properly. After the timer expired I set the Visible property on the layer to false, but still encountered the exception.

I have been doing more testing and have come upon more issues when the WMS Server is not available resulting in Unhandled exceptions.

Here is a scenario under which there is an Unhandled exception:

  1. Start application and successfully retrieve WMS Capabilities.
  2. Successfully display imagery from the WMS Server.
  3. In Windows Network Disable the Network Adapter.
  4. Pan the layer.
  5. The following Unhandled Exception occurs immediately following the SendingWebRequest event:

System.Net.WebException was unhandled
Message: An unhandled exception of type ‘System.Net.WebException’ occurred in ThinkGeo.MapSuite.Wpf.dll
Additional information: The remote name could not be resolved: ‘wmsus.nearmap.com

After restarting the application and connecting to the Internet I did the exact same scenario as above and this time received this exception:

System.Net.WebException was unhandled
Message: An unhandled exception of type ‘System.Net.WebException’ occurred in ThinkGeo.MapSuite.Wpf.dll
Additional information: Unable to connect to the remote server

This happens consistently when the WMS Server or network is not available. You should be able to encounter this same exception in your own applications. Follow the steps outlined above and you should get the same exception.

My feeling is that the MapSuite DLL’s should be robust and check for network connectivity errors and if there is any error then that should be reported to the application. I recommend the ability of the application to define an event that would fire so that the application can handle exceptions due to network connectivity issues as well as any errors that may be encountered. It should include the layer in question as well as the reason.

My application functions in a critical operational environment and cannot be crashing in situations where a WMS Server is unavailable or where there is a network access issue. My application must continue to run as this is a real-time operation.

Please let me know your thoughts.

Thanks,
Dennis

Hi Dennis,

Thanks for your detail scenario and steps, our developer reproduce that.

I don’t know your network get disconnect when the map is running, so please just ignore my suggestion before.

Our developer will look into this and let you know if we get any news.

Regards,

Ethan

Hi Ethan,

Do you have an update for me on this?

Thanks,
Dennis

Hi Dennis,

Our developer still work on it, any update I will let you know.

Regards,

Ethan

Thanks Ethan!

I’ll be happy to test when the developer is ready.

Dennis

Hi Dennis,

As below is the reply from our developer:

  1. Please upgrade all your package to the latest version
    2, Please modify your code like this:

WmsRasterLayer wmsLayer = new WmsRasterLayer(new Uri(“http://howdoiwms.thinkgeo.com/WmsServer.aspx”));
layerOverlay.DrawingExceptionMode = ThinkGeo.MapSuite.Drawing.DrawingExceptionMode.DrawException;
//wmsLayer.DrawingExceptionMode = ThinkGeo.MapSuite.Drawing.DrawingExceptionMode.DrawException;

You can see, the key is set DrawingExceptionMode in overlay level instead of layer level, and it should works.

Any question please let us know.

Regards,

Ethan

hi Ethan,

Thanks very much. Over the next few days I will update my packages and test.

Is this same change being made to V9? I use a WmsRasterLayer in my WMS Server. My WMS server receives requests from my clients and then forwards those request to a public WMS Server via the Internet. So I would like to apply the same checking to my WMS Server.

Thanks,
Dennis

Hi Dennis,

I am not sure whether it’s also applied to V9, because it’s not been changed this time.

If you need to test in V9 please choose the latest development version, I think that should be the latest code.

Regards,

Ethan

hi Ethan,

I’ve updated with the latest packages. I’ve added the Drawing/Drawn exceptions events to my LayerOverlay and now I’m getting the exceptions triggered as well as seeing the message on the map stating ‘the operation has timed out’. The timers I have in SendingWebRequest & SentWebRequest are now working properly and set IsVisible=false on the layer.

Couple things…

When running my client in debug mode invoking Open() on a WmsRasterLayer results in the following exception being returned:
Expected DTD markup was not found. Line 1, Position3.

Below is the exception information. I’m curious why the following value is the SourceUrl?

**http://schemas.opengeospatial.net//wms/1.1.1/capabilities_1_1_1.dtd**

This is not attempting to access the Internet is it? My production environment does not have Internet access.

I am able to GetCapabilities just fine. Just the Open on a WmsRasterLayer results in this exception.

I believe my GetCapabilities works because I’m using a TiledWmsLayer for that. I noticed that there was not a new package for TiledWmsLayer.

This happens on my development machine where the WMS client and server are both running and has nothing to do with whether the network is disabled or not.

I confirmed that this is a newly introduced problem by going back to the prior set of packages. The prior set of packages works in Debug Mode.

Outside of Debug Mode everything works fine.

When I request GetCapabilities by entering the URL in a web browser for my WMS server I get the following returned. I’m only showing you the first few lines as the rest I don’t want to make public. As you can see it has DOCTYPE.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE WMT_MS_Capabilities SYSTEM "http://schemas.opengeospatial.net//wms/1.1.1/capabilities_1_1_1.dtd">
<!-- end of DOCTYPE declaration -->
<WMT_MS_Capabilities version="1.1.1">
<!-- Service Metadata -->
<Service>
<!-- The WMT-defined name for this type of service -->
<Name>OGC:WMS</Name>

Your thoughts?

Thanks,
Dennis

Message = “Expected DTD markup was not found. Line 1, position 3.”

Source = System.Xml

SourceUri = http://schemas.opengeospatial.net//wms/1.1.1/capabilities_1_1_1.dtd

ex.StackTrace
at System.Xml.XmlTextReaderImpl.Throw(Exception e)
at System.Xml.XmlTextReaderImpl.DtdParserProxy.System.Xml.IDtdParserAdapter.Throw(Exception e)
at System.Xml.DtdParser.Throw(Int32 curPos, String res, String arg)
at System.Xml.DtdParser.ScanSubsetContent()
at System.Xml.DtdParser.GetToken(Boolean needWhiteSpace)
at System.Xml.DtdParser.ParseSubset()
at System.Xml.DtdParser.ParseExternalSubset()
at System.Xml.DtdParser.ParseInDocumentDtd(Boolean saveInternalSubset)
at System.Xml.DtdParser.Parse(Boolean saveInternalSubset)
at System.Xml.DtdParser.System.Xml.IDtdParser.ParseInternalDtd(IDtdParserAdapter adapter, Boolean saveInternalSubset)
at System.Xml.XmlTextReaderImpl.ParseDtd()
at System.Xml.XmlTextReaderImpl.ParseDoctypeDecl()
at System.Xml.XmlTextReaderImpl.ParseDocumentContent()
at System.Xml.XmlTextReaderImpl.Read()
at System.Xml.XmlLoader.LoadDocSequence(XmlDocument parentDoc)
at System.Xml.XmlLoader.Load(XmlDocument doc, XmlReader reader, Boolean preserveWhitespace)
at System.Xml.XmlDocument.Load(XmlReader reader)
at System.Xml.XmlDocument.Load(Stream inStream)
at fSQ=.GCU=.Load(Stream inputStream)
at ThinkGeo.MapSuite.Layers.WmsRasterSource.gBo=(String requestCapabilities, IWebProxy proxy, ICredentials credentials)
at ThinkGeo.MapSuite.Layers.WmsRasterSource.fxo=(String url)
at ThinkGeo.MapSuite.Layers.WmsRasterSource.OpenCore()
at ThinkGeo.MapSuite.Layers.RasterSource.Open()
at ThinkGeo.MapSuite.Layers.RasterLayer.OpenCore()
at ThinkGeo.MapSuite.Layers.Layer.Open()
at OriStarWmsClient.TheWmsProviderOriStar.LoadLayer(String TheProvider) in C:\OriStarMappingIncMapSuiteV10Secondary\OriStarWmsClient\TheWmsProviderOriStar.cs:line 186

Source = System.Xml

SourceUri = http://schemas.opengeospatial.net//wms/1.1.1/capabilities_1_1_1.dtd

Hi Dennis,

Thanks for your description.

Your exception is: Expected DTD markup was not found. Line 1, Position3. I search about it, and it seems because the returned through url is not valid XML.

You can also view the StackTrace information, you can see this exception is deep in “XmlDocument.Load(Stream inStream)”, I think the inStream here should be the capability xml stream.

So please try this code to see whether it can be reproduced in your environment:

        WebRequest myRequest = WebRequest.Create(requestCapabilities);
        WebResponse myResponse = WebRequest.GetResponse(webRequest);
        stream = myResponse.GetResponseStream();
        xmlDocument = new XmlDocument();
        xmlDocument.Load(stream);

The requestCapabilities is the capability url.

Please let me know whether it can be reproduced.

Regards,

Ethan

Ethan,

I really don’t see how this is a problem with my application. I feel this is a new problem that has been introduced with the latest packages. This problem never existed before I upgraded.

Also, this only appears while in debug mode. Outside of debug mode it all works.

Will the developers be looking at what was changed in the latest packages?

Please keep in mind that my application is using TiledWmsLayer to GetCapabilities and that works fine, most likely because that package was not updated.

I implemented the sample code you provided and have exactly the same results. It works if the application is invoked outside the debugger and fails in debug mode.

Thanks,
Dennis

Hi Dennis,

The problem is the DOCTYPE string in your XML is not standard format, please modify the “http://schemas.opengeospatial.net//wms/1.1.1/capabilities_1_1_1.dtd” to “http://schemas.opengeospatial.net/wms/1.1.1/capabilities_1_1_1.dtd

Why you meet this exception, that’s because we ignore the DTD in our old logic, but in a few days before, our developer modify the code to include the DTD parse and validation when parsing XML for solve another issue, so the invalid string cannot pass the validation now.

Please modify it and the layer should works.

Regards,

Ethan

hi Ethan,

I changed the string, but alas the issue still persists. It’s odd that it only happens while in the Visual Studio debugger and not when the application exe is invoked.

I searched the Internet for another DOCTYPE and found this one, which works fine:

http://schemas.opengis.net/wms/1.1.1/WMS_MS_Capabilities.dtd

Just for kicks I went back and changed to this one:

"http://schemas.opengeospatial.net/wms/1.1.1/WMS_MS_Capabilities.dtd"

But again does not work.

So these two do not work:
http://schemas.opengeospatial.net/wms/1.1.1/capabilities_1_1_1.dtd
http://schemas.opengeospatial.net/wms/1.1.1/WMS_MS_Capabilities.dtd

And this one does work:

http://schemas.opengis.net/wms/1.1.1/WMS_MS_Capabilities.dtd

Hope this helps the team.

Please let me know if you resolve the issue as I would prefer to switch back to your standard.

And thank you for showing me how to GetCapabilities using WebRequest/WebResponse!

Dennis
OriStar Mapping, Inc.

Hi Dennis,

Thanks for your figure out this. You are right, it should uses http://schemas.opengis.net/wms/1.1.1/WMS_MS_Capabilities.dtd.

This issue is caused by the document type definition(DTD) cannot be found with the “http://schemas.opengeospatial.net/wms/1.1.1/WMS_MS_Capabilities.dtd”,

It because this address is obfuscated, so it is navigated to “http://schemas.opengis.net/”.
we just need to find out the correct DTD file from opengis->wms->1.1.1->WMS_MS_Capabilities.dtd, you already get the correct DTD file.

If there is issue when using MapSuite, please feel free to let us know that.

Thanks
Mark

hi Mark,

Thank you for verifying this for me.

But let me ask one more question please. Does MapSuite depend on Internet access at the time the DTD is verified?

I ask because my production workstations do not have Internet access?

Thanks,
Dennis

Hi Dennis,

The DTD require internet access, and when we tested it the exception will be thrown both for debug or product.

We don’t know why you hadn’t met that, I guess that’s because you set draw exception and the network problem before parse the capability.

And I think you can try to download the DTD file, then modify your XML to point the local DTD file in your server.

Regards,

Ethan

Ethan,

Do you have an example of how to define and reference a local DTD file?

Have you tested the use of a local DTD file?

Thanks,
Dennis

Hi Dennis,

We don’t have a sample and we also don’t tested that.

Because the DTD need to get validation from the url you set in XML, so the “local” means your server machine, it should have a domain name for example: “www.yoursite.com/mine.dtd”, I don’t think something like 192.168.0.x can works for that.

I think you can did a quickly test in the server about it.

Regards,

Ethan