WCF nicht mehr reagiert, nachdem etwa 10 oder so Anrufe (Drosselung)
https://stackoverflow.com/questions/739312
-
09-09-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianFrage
Ich habe einen WCF-Dienst und eine Anwendung mit einem Service-Verweise darauf, und mit der Anwendung habe ich eine Schleife und in jeder Iteration es einen Aufruf eine Methode in diesem wcf web-Service zu machen.
Das Problem ist, dass nach etwa 9 Anrufen oder so, es einfach nicht mehr ... und wenn Sie Pause Taste von VS treffen, werden Sie sehen, dass es auf der Linie festsitzt, wo sie den Anruf tätigen.
Nach einiger Zeit darauf gewartet, diese Timeout geworfen wird:
Der Anforderungskanal Zeitüberschreitung, während Warten auf eine Antwort nach 00: 00: 59,9970000. Erhöhen Sie den Timeout Wert auf den Ruf weitergegeben anfordern oder erhöht den Wert auf der Sendtimeout Bindung. Die Zeit, um diese zugeteilt Operation kann ein Abschnitt eines gewesen mehr Timeout.
erforschte ich ein wenig auf das, und fand einige Lösungen, die die Bearbeitung der app.config in der Anwendung beteiligt, und hier sind Auszüge davon:
<serviceBehaviors>
<behavior name="ThrottlingIssue">
<serviceThrottling maxConcurrentCalls="500" maxConcurrentSessions="500" />
</behavior>
</serviceBehaviors>
.
<readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647"
maxArrayLength="2147483647"
maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647" />
Dann, nachdem ich Debuggen beenden, nach ein paar Minuten, wird eine Fehlermeldung erscheint mir zu sagen, dass ein Schwerwiegender Fehler aufgetreten ist.
Wie kann ich dieses Problem beheben? Ich habe nicht dieses Problem haben, wenn ich mit einem normalen Web-Service arbeitete.
Als Referenz ist hier die ganze app.config:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.serviceModel>
<behaviors>
<serviceBehaviors>
<behavior name="ThrottlingIssue">
<serviceThrottling maxConcurrentCalls="500" maxConcurrentSessions="500" />
</behavior>
</serviceBehaviors>
</behaviors>
<bindings>
<wsHttpBinding>
<binding name="WSHttpBinding_IDBInteractionGateway" closeTimeout="00:01:00"
openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"
bypassProxyOnLocal="false" transactionFlow="false" hostNameComparisonMode="StrongWildcard"
maxBufferPoolSize="524288" maxReceivedMessageSize="65536"
messageEncoding="Text" textEncoding="utf-8" useDefaultWebProxy="true"
allowCookies="false">
<readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647"
maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647" />
<reliableSession ordered="true" inactivityTimeout="00:10:00"
enabled="false" />
<security mode="Message">
<transport clientCredentialType="Windows" proxyCredentialType="None"
realm="" />
<message clientCredentialType="Windows" negotiateServiceCredential="true"
algorithmSuite="Default" establishSecurityContext="true" />
</security>
</binding>
</wsHttpBinding>
</bindings>
<client>
<endpoint address="http://localhost:28918/DBInteractionGateway.svc"
binding="wsHttpBinding" bindingConfiguration="WSHttpBinding_IDBInteractionGateway"
contract="DBInteraction.IDBInteractionGateway" name="WSHttpBinding_IDBInteractionGateway">
<identity>
<dns value="localhost" />
</identity>
</endpoint>
</client>
</system.serviceModel>
</configuration>
[Update] Lösung:
Offenbar nach jedem fordern Sie die Verbindung zum Close haben ... Ich bin jetzt das Schließen der Verbindung nach jeder Anforderung und es funktioniert wie ein Charme.
Obwohl das, was ich kann immer noch nicht verstehen, dass in meinem app.config ist, dass ich zu 500 meine maxConcurrentCalls und MaxConcurrentSessions gesetzt, und doch kann ich nur 10. Wer machen für diese eine jede Antwort hat ? (Vielleicht habe ich etwas falsch in meinem app.config oben gepostet)
Die Antwort auf die obige Frage (jetzt gestrichelt) ist, weil ich den Client app.config redigierte, nicht die Service-Konfigurationsdatei (web.config)
Lösung
Die Standardanzahl der erlaubten gleichzeitigen Verbindungen ist 10.
Wahrscheinlich wird Ihr Client die Verbindungen nicht geschlossen wird.
Um die Anzahl der gleichzeitigen Anrufe zu erhöhen, müssen Sie Ihr Verhalten an den Service-Konfiguration hinzufügen, nicht auf dem Client.
Andere Tipps
Ein Aufruf clientservice.close () wird das Problem lösen.
Ich lief in dieses Problem in dieser Woche und ich war ziemlich nicht in der Lage, herauszufinden, was los war.
Ich habe tatsächlich meinen Ruf zu meinem Dienst ändern, um das Service-Client Dispose(), aber es schien keine Wirkung zu haben. Offenbar gab es einen weiteren Service-Aufruf irgendwo lauert.
Was interessant sein kann, zu beachten ist, was mich entscheiden, dass dies nicht das Problem: diese Grenze nicht auf die tatsächliche Anzahl der Socket-Verbindungen zu dem Webservice in Beziehung steht. Wenn Sie die maxConcurrentSessions Grenze erreicht, gibt es nach wie vor nur eine Ist-Socket-Verbindung . Ich war die Überprüfung dieses mit netstat, die mich zu dem falschen Schluss gebracht. Also, nicht verwechseln Sitzungen mit Steckdosen .
Wir verfügen über Schnittstellen für alle unsere WCF-Dienste definiert, so plane ich dieses Muster in meinem Code anzupassen jetzt:
IMyService service = new MyServiceClient();
using (service as IDisposable)
{
service.MyServiceMethod();
}
Was auch interessant ist, ist, dass das Problem bei mir nicht auftreten, wenn die Dienste (und Website) auf IIS gehostet wurden. Die Konfiguration ist (fast) identisch, doch konnte ich dieses Verhalten auf dieser Maschine nicht reproduzieren. Ich denke, das ist eine gute Sache:)
@ John Saunders (über Variablenzuweisung in using):
Normalerweise mache ich die variable Zuordnung in der using Anweisung setzen. Aber die IMyService, die generiert wird nicht implizit konvertierbar IDisposable. Wenn Sie wirklich die Zuordnung dort wollte, nehme ich die Alternative wäre:
IService service;
using ((service = new ServiceClient()) as IDisposable)
{
}
Das ist immer noch das Problem des variablen Umfangs läßt obwohl sein falsch. Der Verweis auf IService service ist unbrauchbar, aber immer noch in ihrem Umfang. So wäre dies besser in dieser Hinsicht:
using (IDisposable serviceDisposable = new ServiceClient())
{
IService service = (IService)serviceDisposable;
}
Das verlangt von mir einen zusätzlichen Variablennamen obwohl einzuführen. * Meh *
Dies kann durch Erstellen Singletonklasse als Schnittstelle zwischen Web-Service-Referenz und Anwendung gelöst werden. Dann wird es nur eine Instanz des Dienstverweises erstellen.
class ServiceInterface
{
private static ServiceInterface _instance;
private ServiceClient _service = new ServiceClient ;
private ServiceInterface()
{
//Prevent accessing default constructor
}
public static ServiceInterface GetInstance()
{
if(_instance == null)
{
_instance = new ServiceInterface();
}
return _instance;
}
// You can add your functions to access web service here
Public int PerformTask()
{
return _service.PerformTask();
}
}
Sie können configure Tracing und die Schleife laufen? Es kann sein, dass der Kanal bemängelt wird immer und verursacht den Client zu Zeit aus.
Nach dem Ziehen meine Haare über ein viel ähnliches Problem, das nicht entweder durch Close() oder Dispose() gelöst wurde ich möchte eine einfache Lösung hinzuzufügen, die meinen Tag gemacht, und zwar durch die Erhöhung der ServicePointManager.DefaultConnectionLimit , die standardmäßig 2 ist.
„Die DefaultConnectionLimit Eigenschaft legt die Standard maximale Anzahl gleichzeitiger Verbindungen, die der Servicepoint Objekt an die ConnectionLimit Eigenschaft zuordnet, wenn Servicepoint Objekte zu schaffen.“
In meinem Fall meiner Bewerbung erfolgreich zu meinem Remote-Service 2 mal angeschlossen, auf dem dritten Versuch es einfach nicht auf den Dienst zu verbinden versuchte. Stattdessen wartete er eine Weile vor, wie oben in der Frage mit der gleichen Fehlermeldung Zeitüberschreitung. Zunehmender DefaultConnectionLimit aufgelöst dies. So fügen Sie dieses Verhalten war auf die Frustration etwas zufällig -. In einem Fall von 10 die Webservice wurde erfolgreich mehrere aufgerufen (> 2) mal
Die Lösung stammt, und werden weiter diese beiden Fäden diskutiert: WCF-Timeout-Ausnahme-detailed- Untersuchung und wcf-Service-Drosselung . löste mein Problem.
