Azure cmdlets timeout workaround/hack

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:

C:\WASMCmdlets\code\Microsoft.Samples.WindowsAzure.ServiceManagement\ResourceModel\ServiceManagementHelper.cs

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…. 😐

FIX: WCF Streamed webservice message exceeding 65536 bytes despite “correct” maxReceivedMessageSize setting.

“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.

DataContractSerializer threw System.NullReferenceException: Object reference not set to an instance of an object..

I got the following exception during serialization of an object:
 System.NullReferenceException: Object reference not set to an instance of an object..

System.Runtime.Serialization.XmlObjectSerializerWriteContext.OnHandleIsReference(XmlWriterDelegator xmlWriter, DataContract contract, Object obj)
System.Runtime.Serialization.XmlObjectSerializerWriteContext.SerializeWithXsiType(XmlWriterDelegator xmlWriter, Object obj, RuntimeTypeHandle objectTypeHandle, Type objectType, Int32 declaredTypeID, RuntimeTypeHandle declaredTypeHandle, Type declaredType)
System.Runtime.Serialization.XmlObjectSerializerWriteContext.InternalSerialize(XmlWriterDelegator xmlWriter, Object obj, Boolean isDeclaredType, Boolean writeXsiType, Int32 declaredTypeID, RuntimeTypeHandle declaredTypeHandle)
System.Runtime.Serialization.XmlObjectSerializerWriteContext.InternalSerializeReference(XmlWriterDelegator xmlWriter, Object obj, Boolean isDeclaredType, Boolean writeXsiType, Int32 declaredTypeID, RuntimeTypeHandle declaredTypeHandle)
WriteEventEditionToXml(XmlWriterDelegator , Object , XmlObjectSerializerWriteContext , ClassDataContract )
System.Runtime.Serialization.ClassDataContract.WriteXmlValue(XmlWriterDelegator xmlWriter, Object obj, XmlObjectSerializerWriteContext context)
System.Runtime.Serialization.XmlObjectSerializerWriteContext.WriteDataContractValue(DataContract dataContract, XmlWriterDelegator xmlWriter, Object obj, RuntimeTypeHandle declaredTypeHandle)
System.Runtime.Serialization.XmlObjectSerializerWriteContext.SerializeWithoutXsiType(DataContract dataContract, XmlWriterDelegator xmlWriter, Object obj, RuntimeTypeHandle declaredTypeHandle)
System.Runtime.Serialization.DataContractSerializer.InternalWriteObjectContent(XmlWriterDelegator writer, Object graph)
System.Runtime.Serialization.DataContractSerializer.InternalWriteObject(XmlWriterDelegator writer, Object graph)
System.Runtime.Serialization.XmlObjectSerializer.WriteObjectHandleExceptions(XmlWriterDelegator writer, Object graph)
System.Runtime.Serialization.XmlObjectSerializer.WriteObject(XmlDictionaryWriter writer, Object graph)
System.Runtime.Serialization.XmlObjectSerializer.WriteObject(Stream stream, Object graph)
ReedExpo.Nova.UnitTesting.Events.EventHandlerTests.Test_TestSerializeEventEdition() in D:ProjectsNOVA PlatformWorkingReedExpo.NovaReedExpo.Nova.UnitTestingEventsEventHandlerTests.cs: line 85 

Turns out there were two reasons I encountered this:

  1. I hadn’t marked the type as a [DataContract] which meant public properties not marked as [DataMember] were still being serialized (I believe this happens post 3.5 SP1)
  2. More significantly, the return type of the property was a generic IList<MyType> (if I changed this to be a concrete class then the error goes away).