none
Request data getting lost with net.tcp and WAS RRS feed

  • Question

  • I'm trying to adapt an existing, working service of some complexity to work over net.tcp so that I can benchmark it against basic http for some performance scenarios with our actual service. We currently use IIS, and so I am trying to get a comparable case running against WAS on my box running Server 2008.

    After some surprising difficulties, I was able to get the client to connect properly over net.tcp, but now I'm running into a surprising issue, where data gets lost in the request.

    I have a data contract object in a form like Foo:

      [Serializable]
      [DataContract(Name = "Foo")]
      [KnownType(typeof(Foo))]
      public class Foo: ABaseClass, IAnInterface
      {
        [DataMember]
        public string AField { get; set; }
    
        [DataMember]
        public string AnotherField { get; set; }

    }
    The method I'm calling is of the form

      [ServiceContract(Namespace = "http://some.domain.com/SomeInterfaceService")]
      public interface ISomeInterface
      {
        [OperationContract]
        [WebGet(ResponseFormat = WebMessageFormat.Json)]
        UserResponse AddFooToDb(Foo foo, SomethingElse somethingElse);
    
        // more here ...
      }
    
    
    What's happening is that while the SomethingElse object is arriving intact at the server, the Foo object is losing its field values. The object arrives, but its fields are emptied out.

    The binding was originally

    <netTcpBinding>
      <binding name="EdpgTcpBinding" portSharingEnabled="true" >
    <security mode="None" /> </binding> </netTcpBinding>
    and then I expanded it with settings based on the http binding I have:


    <netTcpBinding>
      <binding name="EdpgTcpBinding" portSharingEnabled="true" maxReceivedMessageSize="65536000">
        <readerQuotas maxArrayLength="52428800" maxBytesPerRead="4096"
                      maxDepth="32" maxNameTableCharCount="16384"
                      maxStringContentLength="8192"/>
        <security mode="None" />
      </binding>
    </netTcpBinding>
    
    
    But this didn't solve the problem.

    Any ideas why this data would be getting lost, and (more importantly) how I can send it properly?

    Thanks!
    Tuesday, June 30, 2009 12:59 AM

Answers

  • My guess is that the Foo type in teh client and service are in different .NET namespaces. The default behavior for the data contract serializer is, unless you explicitly set it, the .NET namespace of the type is used as part of the XML namespace of the serialized message. So in effect, the client is sending data that the service doesn;t recognise as its expecting XML in a different namespace.

    Trty setting the Namespace explicitly on the data contract on client and service to the same thing, e.g.

    [DataContract( Name="Foo", Namespace="urn:foo")]


    Richard Blewett, thinktecture - http://www.dotnetconsult.co.uk/weblog2
    Twitter: richardblewett
    Tuesday, June 30, 2009 12:45 PM
    Moderator

All replies

  • Hi unique :)

    can you provide a ready to run VS project?

    Regards,
    John
    Tuesday, June 30, 2009 2:03 AM
  • My guess is that the Foo type in teh client and service are in different .NET namespaces. The default behavior for the data contract serializer is, unless you explicitly set it, the .NET namespace of the type is used as part of the XML namespace of the serialized message. So in effect, the client is sending data that the service doesn;t recognise as its expecting XML in a different namespace.

    Trty setting the Namespace explicitly on the data contract on client and service to the same thing, e.g.

    [DataContract( Name="Foo", Namespace="urn:foo")]


    Richard Blewett, thinktecture - http://www.dotnetconsult.co.uk/weblog2
    Twitter: richardblewett
    Tuesday, June 30, 2009 12:45 PM
    Moderator
  • Close enough -- it wasn't a namespace problem, it was a problem with an out of date service reference. Thanks for helping me narrow down the problem! :-)

    For some reason, I also had to relaunch visual studio with the /resetskippkgs flag before it would let me update the service reference.


    AUDN

    P.S. Thanks, John, for trying to help as well!
    Tuesday, June 30, 2009 6:11 PM