views:

106

answers:

1

I have a wcf service consumed by a silverlight 3 control. The Silverlight client uses a basicHttpBindinging that is constructed at runtime from the control's initialization parameters like this:

public static T GetServiceClient<T>(string serviceURL)
{
    BasicHttpBinding binding = new BasicHttpBinding(Application.Current.Host.Source.Scheme.Equals("https", StringComparison.InvariantCultureIgnoreCase)
            ? BasicHttpSecurityMode.Transport : BasicHttpSecurityMode.None);
    binding.MaxReceivedMessageSize = int.MaxValue;
    binding.MaxBufferSize = int.MaxValue;

    binding.Security.Mode = BasicHttpSecurityMode.TransportCredentialOnly;

    return (T)Activator.CreateInstance(typeof(T), new object[] { binding, new EndpointAddress(serviceURL)});
 }

The Service implements windows security. Calls were returning as expected until the result set increased to several thousand rows at which time HTTP 401.1 errors were received.

The Service's HttpBinding defines closeTime, openTimeout, receiveTimeout and sendTimeOut of 10 minutes.

If I limit the size of the resultset the call suceeds.

Additional Observations from Fiddler: When Method2 is modified to return a smaller resultset (and avoid the problem), control initialization consists of 4 calls:

  1. Service1/Method1 -- result:401
  2. Service1/Method1 -- result:401 (this time header includes element "Authorization: Negotiate TlRMTV..."
  3. Service1/Method1 -- result:200
  4. Service1/Method2 -- result:200 (1.25 seconds)

When Method2 is configured to return the larger resultset we get:

  1. Service1/Method1 -- result:401
  2. Service1/Method1 -- result:401 (this time header includes element "Authorization:Negotiate TlRMTV..."
  3. Service1/Method1 -- result:200
  4. Service1/Method2 -- result:401.1 (7.5 seconds)
  5. Service1/Method2 -- result:401.1 (15ms)
  6. Service1/Method2 -- result:401.1 (7.5 seconds)
+1  A: 

The issue was configuration of the Service Behavior. This did the trick:

<behavior name="SRMS.Services.GraphicPointServiceBehavior">
    <serviceMetadata httpGetEnabled="true"/>
 <serviceDebug includeExceptionDetailInFaults="true"/>
<dataContractSerializer maxItemsInObjectGraph="2147483647"/>

See the post by Daniel Bergsten here: more information

sympatric greg
BTW, the xml output of the server trace was malformed, so it was much easier to read when created with System.Diagnostics.TextWriterTraceListener
sympatric greg