configure WCF receive location in Biztalk

问题:

We have an application in BizTalk which has started to report errors. It seems to be related to maxItemsInObjectGraph, which for the Web application has been fixed by amending the CONFIG file. However it still fails in BizTalk. I was told i could configure the receive location in BitTalk and set it there? However i only seem to be able to increase the maximum received message size here, not the MaxitemsinGraph. I am new to BizTalk but any ideas would be greatly appreciated.

Error reports as

Error Description: System.ServiceModel.CommunicationException: An error occurred 
while  receiving the HTTP response to http://servername:8448/ServicePortal.Service/ApplicationServices.svc. This could be due to the service endpoint binding not using the HTTP protocol. This could also be due to an HTTP request context being aborted by the server (possibly due to the service shutting down). See server logs for more details. ---> System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a receive. ---> System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host

Thanks Richard

回答1:

This is defined in an endpoint behaviour:

     <endpointBehaviors>      <behavior name="wsServiceBehaviour">        
 <dataContractSerializer
 maxItemsInObjectGraph="6553600"/>     
 </behavior>    </endpointBehaviors>

Be sure that you tell your endpoint to uses this behaviour:

  <client>    
   <endpoint address="http://localhost:8379/HelloService/" 
           binding="basicHttpBinding"               
           behaviorConfiguration="wsServiceBehaviour"  
          contract="ServiceContracts.IHello"                 
          name="BasicHttpBinding_IIHello" />  
 </client>

回答2:

I have had the same error message, but the problem was related to the service side.

The application pool was suppose to recycle when "Maximum virtual memory" reached a certain amount, which occured. That should not be any problem, any current threads should be allowed to finish, but in our case the service took more time to finished than allowed by "Shutdown time limit". The application pool recycling made the service side cut the connection.

This should be reproducable if you can test the same service with same request message with another application, a windows test app for example. Your technicians can certainly see in logs if the application pool has recycled.