WCF ERROR: le serveur n'a pas fourni de réponse significative;
s'il vous plaît, quelqu'un peut m'aider à découvrir ce qui s'est passé. J'ai mon service WCF qui a bien fonctionné, et maintenant j'ai soudain cette erreur:
Le serveur n'a pas fourni de réponse significative; cela peut être dû à une non-concordance des contrats, à un arrêt prématuré de la session ou à une erreur interne erreur du serveur
Je dois dire que cela fonctionne toujours lorsque je sélectionne des milliers d'enregistrements, mais lorsque les données sont énormes, je reçois cette erreur, bien qu'avant, cela fonctionnait bien!
private static string ConnString = "Server=127.0.0.1; Port=5432; Database=DBname; User Id=UName; Password=MyPassword;"
DataTable myDT = new DataTable();
NpgsqlConnection myAccessConn = new NpgsqlConnection(ConnString);
myAccessConn.Open();
string query = "SELECT * FROM Twitter";
NpgsqlDataAdapter myDataAdapter = new NpgsqlDataAdapter(query, myAccessConn);
myDataAdapter.Fill(myDT);
foreach (DataRow dr in myDT.Rows)
{
**WHEN I HAVE TOO MANY RECORDS IT STOPS HERE**
...
web.config
<configuration>
<system.web>
<compilation debug="false" targetFramework="4.0" />
<httpRuntime maxRequestLength="2147483647" executionTimeout="100000" />
</system.web>
<system.diagnostics>
<trace autoflush="true" />
<sources>
<source name="System.ServiceModel"
switchValue="Information, ActivityTracing"
propagateActivity="true">
<listeners>
<add name="traceListener" type="System.Diagnostics.XmlWriterTraceListener" initializeData="Traces4.svclog"/>
</listeners>
</source>
</sources>
</system.diagnostics>
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="BasicHttpBinding_IDBService" closeTimeout="00:30:00"
openTimeout="00:30:00" receiveTimeout="00:30:00" sendTimeout="00:30:00"
allowCookies="false" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"
maxBufferSize="2147483647" maxBufferPoolSize="2147483647" maxReceivedMessageSize="2147483647"
messageEncoding="Text" textEncoding="utf-8" transferMode="Streamed"
useDefaultWebProxy="true">
<readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647" maxArrayLength="2147483647"
maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647" />
<security mode="None">
<transport clientCredentialType="None" proxyCredentialType="None"
realm="" />
<message clientCredentialType="UserName" algorithmSuite="Default" />
</security>
</binding>
</basicHttpBinding>
</bindings>
<client>
<endpoint address="" binding="basicHttpBinding"
bindingConfiguration="BasicHttpBinding_IDBService" contract="DBServiceReference.IDBService"
name="BasicHttpBinding_IDBService" />
</client>
<behaviors>
<serviceBehaviors>
<behavior name="">
<serviceMetadata httpGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="true" />
<dataContractSerializer maxItemsInObjectGraph="2147483646" />
</behavior>
</serviceBehaviors>
</behaviors>
<serviceHostingEnvironment aspNetCompatibilityEnabled="false" multipleSiteBindingsEnabled="true" />
</system.serviceModel>
</configuration>
client config (édité)
<configuration>
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="BasicHttpBinding_IRouteService" maxBufferSize="2147483647"
maxReceivedMessageSize="2147483647">
<security mode="None" />
</binding>
<binding name="BasicHttpBinding_IDBService" closeTimeout="00:30:00"
openTimeout="00:30:00" receiveTimeout="00:30:00" sendTimeout="00:30:00"
maxBufferSize="2147483647" maxReceivedMessageSize="2147483647"
transferMode="Buffered" >
<security mode="None" />
</binding>
</basicHttpBinding>
<customBinding>
<binding name="CustomBinding_IRouteService">
<binaryMessageEncoding />
<httpTransport maxReceivedMessageSize="2147483647"
maxBufferSize="2147483647" />
</binding>
</customBinding>
</bindings>
<client>
<endpoint address="http://dev.virtualearth.net/webservices/v1/routeservice/routeservice.svc"
binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_IRouteService"
contract="BingRoutingService.IRouteService" name="BasicHttpBinding_IRouteService" />
<endpoint address="http://dev.virtualearth.net/webservices/v1/routeservice/routeservice.svc/binaryHttp"
binding="customBinding" bindingConfiguration="CustomBinding_IRouteService"
contract="BingRoutingService.IRouteService" name="CustomBinding_IRouteService" />
<endpoint address="" binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_IDBService"
contract="DBServiceReference.IDBService" name="BasicHttpBinding_IDBService" />
</client>
</system.serviceModel>
</configuration>
Dans mon dossier scvlog je n'ai aucune exception! Je n'ai aucune autre idée de ce que je peux faire d'autre pour comprendre où se situe le problème. S'il vous plaît, aidez-moi!
Une réponse différente, juste au cas où quelqu'un arriverait ici comme je cherchais une réponse générale à la question.
Il semble que le DataContractSerializer qui effectue le travail de base est incroyablement complexe, mais ne transmet pas toujours la véritable erreur au client. Le processus du serveur meurt immédiatement après la panne - aucune erreur ne peut donc être trouvée. Dans mon cas, le problème était une énumération qui était utilisée comme drapeaux, mais non décorée avec l'attribut [Flags] (pointilleux ou quoi!).
Pour le résoudre, j'ai créé une instance du sérialiseur et inspecté l'erreur dans le débogueur; voici un extrait de code puisque je l’ai sous la main.
EDIT: En réponse à la demande dans les commentaires ...
Extrait de code modifié pour montrer la méthode d'assistance que j'utilise maintenant. Un peu comme avant, mais dans un wrapper générique pratique.
public static T CheckCanSerialize<T>(this T returnValue) {
var lDCS = new System.Runtime.Serialization.DataContractSerializer(typeof(T));
Byte[] lBytes;
using (var lMem1 = new IO.MemoryStream()) {
lDCS.WriteObject(lMem1, returnValue);
lBytes = lMem1.ToArray();
}
T lResult;
using (var lMem2 = new IO.MemoryStream(lBytes)) {
lResult = (T)lDCS.ReadObject(lMem2);
}
return lResult;
}
Et pour utiliser cela, au lieu de renvoyer un objet, renvoyez-le après avoir appelé la méthode d'assistance, afin
public MyDodgyObject MyService() {
... do lots of work ...
return myResult;
}
devient
public MyDodgyObject MyService() {
... do lots of work ...
return CheckCanSerialize(myResult);
}
Toute erreur de sérialisation est alors renvoyée avant le service cesse de faire attention, et peut donc être analysé dans le débogueur.
Remarque; Je ne recommanderais pas de laisser l'appel dans le code de production, il a la surcharge de sérialiser et de désérialiser l'objet, sans aucun avantage réel une fois que le code est débogué.
J'espère que cela aide quelqu'un - j'ai perdu environ 3 heures à essayer de le localiser.
Je ne sais pas si cela peut vraiment être une réponse, mais j'ai essayé de changer dans web.config de <security mode="None" /> à <security mode="Transport" /> et ça a fonctionné !!!
Je voudrais faire attention que cette partie ne doit être modifiée que dans web.config et que la configuration du client reste <security mode="None" />, car avec Transport dans les deux cas, cela ne fonctionne pas!
Alors après cela, j'ai décidé d'essayer de revenir à None security et cela a fonctionné pendant quelques minutes, puis arrêté à nouveau, et l'erreur est revenue:
Le serveur n'a pas fourni de réponse significative. cela peut être dû à une incompatibilité de contrat, à un arrêt prématuré de la session ou à une erreur de serveur interne
Donc, il semble que la solution dans mon cas est de définir dans web.config
security mode to Transport
Dans mon cas, je travaillais sur un projet d'application Windows communiquant avec un service Web WCF . Le service Web, utilisant netTcpBinding, renvoyait un objet Stream (une image).
Comme l'application Windows n'a pas de fichier de configuration, les valeurs par défaut sont utilisées pour les liaisons. Et le simple fait d’étendre MaxReceivedMessageSize sur le code d’arrière-plan client a résolu mon problème.
var API = new StreamService.StreamServiceClient(
new System.ServiceModel.NetTcpBinding(System.ServiceModel.SecurityMode.None)
{
MaxReceivedMessageSize = 2147483647
},
new System.ServiceModel.EndpointAddress("net.tcp://machine/app/service.svc")
);
Parfois, ce problème est dû à un message surdimensionné qui a été coupé en raison de valeurs par défaut dans la liaison.
Vous devez ajouter maxReceivedMessageSize, maxBufferPoolSize et maxBufferSize avec des valeurs suffisamment grandes pour la liaison dans votre fichier app.config - cela devrait suffire :)
Exemple:
<bindings>
<netTcpBinding>
<binding
name="ExampleBinding" closeTimeout="00:01:00"
maxReceivedMessageSize="73400320"
maxBufferPoolSize="70000000"
maxBufferSize="70000000"/>
</netTcpBinding>
</bindings>
Bonne chance!
Dans mon cas, je travaillais sur une application MVC et j'ai changé
maxReceivedMessageSize ="10000000"
à
maxReceivedMessageSize ="70000000"
et ça a fonctionné! C'est parce que la réponse du serveur Web dépasse maxReceivedMessageSize ="10000000",
J'ai donc augmenté maxReceivedMessageSize à maxReceivedMessageSize ="70000000".
Pour moi, c'était une liste de chargement paresseux d'éléments extraits de la base de données.
Le récepteur WCF essaierait de les parcourir, ce qui essayerait d’aller à la base de données, ce qui ne pourrait évidemment pas fonctionner.
D'après mon expérience de cette erreur, il suffit de consulter le journal des événements de l'ordinateur hôte du service pour savoir quelle est l'exception réelle.
Dans BizTalk, nous avons l'habitude de résoudre ce problème.
Généralement, le problème se produira en raison de la taille du message du service. Nous devons donc augmenter la taille du message reçu de 65 356 à 2 365 360. Cela a fonctionné pour moi.