I’ve noticed that the .NET DataContractJsonSerializer doesn’t recognise the __type if you format the JSON and it’s not the first __type in the document.
To workaround this but still have semi-formatted JSON, ensure the “__type” immediately follows the opening curly brace.
I know that fixing a timeout issue by increasing the timeout is probably the worst idea but hey, needs must…. 🙂
When you install the Azure cmdlets, it compiles the source code. Therefore allows you to amend the source code before this happens:
Change the CreateServiceManagementChannel methods to include these lines:
factory.Endpoint.Binding.SendTimeout = TimeSpan.FromMinutes(2);
factory.Endpoint.Binding.ReceiveTimeout = TimeSpan.FromMinutes(2);
…before the factory.CreateChannel();
Then run the startHere.cmd again otherwise you’ll get a strong name exception.
However I still get timeouts for GetDeployment, this is no longer a client side WCF timeout issue as I tried using HttpWebRequest against the ServiceManagement REST API setting both Timeout and ReadWriteTimeout. It appears this is a server side timeout of around 2 minutes resulting in
“The underlying connection was closed: The connection was closed unexpectedly.”
I’ve not found a way around this yet other than to try another approach that doesn’t use/need this method.
UPDATE 8/4/2011: About 5pm last night GMT this issue went away and the GetDeployment call that was taking over two minutes now runs in 8 seconds – we didn’t change anything so…. 😐
“The maximum message size quota for incoming messages (65536) has been exceeded. To increase the quota, use the MaxReceivedMessageSize property on the appropriate binding element.”
The config file already had a bindingConfiguration specified for the endpoint that had a maxReceivedMessageSize=”67108864″ attribute. But it still wasn’t making a difference.
Fix: In the end it turned out that it was the <service name=”MyService”> element that was incorrect, it should have been fully qualified to the class name of the service, i.e. – <service name=”MyNamespace.MyService”> without this it was basically ignoring this configuration and falling back to default of 65536 max message size.