ansaurus

Question

Answer 1

A:

You show an exception on the client; what happens when you attach a debugger on the server (or turn on logging), see anything useful there?

Brian 2009-09-07 12:03:13

There is no error on the server side. It successfully constructs and returns the return object.

Nathan Ridley 2009-09-07 12:08:15

Hm. Any chance server and client have mismatched contracts (e.g. server contract changed, but client did not)? Might need to use e.g. Fiddler to see what's going on the wire.

Brian 2009-09-07 12:15:48

No, I ran an update on the service reference just to check.

Nathan Ridley 2009-09-07 12:30:51

Do other methods on the contract interface work? What if you just return an 'int'? I would guess serialization maybe next, and try various data types to see if you can come up with conditions for it failing/succeeding...

Brian 2009-09-07 12:38:41

I have another service side by side which returns simpler types and it works fine.

Nathan Ridley 2009-09-07 12:41:01

Sounds like you have a recipe for a binary search of the problem. You have a service with simple types that works. You have a service with complex types that doesn't. Start transforming the simple one into the complex one, step by step, until it fails, and find different axes of failure, until you understand the issue.

Brian 2009-09-10 06:47:53

Answer 2

A:

This might be caused by a message too long. You should try to change the limits by editing your app.config like this:

<binding name="WebBinding" maxBufferPoolSize="2147483647" maxReceivedMessageSize="2147483647">
  <readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647"
    maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647" />

Brann 2009-09-07 12:03:48

Thanks for the response. The third sentence in the opening paragraph of the question reads: "In my debugging, the total byte size of the serialized message is well under the default 65535 byte threshold."

Nathan Ridley 2009-09-07 12:07:34

@Nathan : the message length is not the only meaningfull threshold. Namely, check the maxArrayLength parameter

Brann 2009-09-07 12:27:52

Have tried that too, cheers. Still get the error though.

Nathan Ridley 2009-09-07 12:30:19

Answer 3

A:

Could it be that your server just takes a tad too long to put together the response? The default "sendTimeout" on the client is only 60 seconds - you could try to increase that to something higher:

<binding name="TweakedBinding" sendTimeout="120" />

What does your client config look like? What binding are you using? What security settings?

Marc

UPDATE:
could you add the service debug behavior to your service, so that you'd get more debug and error info on the client end when something goes wrong??

<behaviors>
  <serviceBehavior>
    <behavior name="YourBehaviorName">
       <serviceDebug includeExceptionDetailInFaults="True" />
    </behavior>
  </serviceBehavior>
</behaviors>

marc_s 2009-09-07 12:31:54

No, the response is very quick. I've just updated the question to show a screenshot of the debugger info.

Nathan Ridley 2009-09-07 12:37:31

The binding and security configuration are all default values generated by Visual Studio. The service is via ASP.Net and set to run via IIS rather than the built-in web server.

Nathan Ridley 2009-09-07 12:43:10

ansaurus

tags:

views:

answers:

How do I resolve this WCF exception?

related questions