configurer l'emplacement de réception WCF dans Biztalk

Question

Nous avons une application dans BizTalk qui a commencé à signaler des erreurs. Il semble être lié à maxItemsInObjectGraph, qui pour l'application Web a été corrigé en modifiant le fichier CONFIG. Cependant, il échoue toujours dans BizTalk. On m'a dit que je pouvais configurer l'emplacement de réception dans BitTalk et le définir là? Cependant, je semble seulement être en mesure d'augmenter la taille maximale des messages reçus ici, pas le MaxitemsinGraph. Je suis nouveau à BizTalk mais toutes les idées seraient grandement appréciées.

rapports d'erreur comme

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

Merci Richard

Answer 1

Ceci est défini dans un comportement de point final:

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

Assurez-vous que vous dites à votre point final à utilise ce comportement:

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

Answer 2

J'ai eu le même message d'erreur, mais le problème était lié au côté service.

Le pool d'applications était supposé être recyclé lorsque "Mémoire virtuelle maximale" atteignait une certaine quantité, ce qui s'est produit. Cela ne devrait pas être un problème, tous les threads actuels devraient être autorisés à terminer, mais dans notre cas, le service a pris plus de temps pour terminer que permis par "Limite de temps d'arrêt". Le recyclage du pool d'applications a amené le côté service à couper la connexion.

Cela devrait être reproductible si vous pouvez tester le même service avec le même message de demande avec une autre application, une application de test de Windows par exemple. Vos techniciens peuvent certainement voir dans les journaux si le pool d'applications a été recyclé.