Moin Moin,
ich bin gerade dabei ein Projekt fertig zu stellen und hänge in den letzten Feinschliffen.
Während der QA Tests ist mir aufgefallen dass ein bestimmter Funktionspart der DLL nach regelmäßigem Nutzen dazu führt dass der Prozess sich kurzzeitig aufhängt / stehen bleibt / einfriert.
Ich habe mal durchs Forum gestöbert und dabei auf einige Beiträge gestoßen welche das gleiche Beschrieben aber für mich gab es in keinen der beschriebenen Fällen eine wirklich mitgeteilte Lösung.
The Task at Hand / Was wir denn genau machen.
Ich muss eine URL aufrufen und and diese Parameter übergeben.
An sich eine doch recht Simple Aufgabe die mit Onboard Mittel in C# recht schnell gelöst wird.
Hier jetzt mal den Code Snippet was ich denn mache.
private bool clfHttpPost(string parameters) {
string f = "clfHttpPost(...)";
clfLogMsg(f, "Function called");
clfLogMsg(f, " - Parameters = " + parameters);
clfLogMsg(f, " - Uri = " + _uri);
if (_uri == null || _uri.Length < 1) {
clfErrorHandler("Error", f, "Can not set Message to read due to URI being empty", null);
return false;
}
clfLogMsg(f, "Creating HttpWRequest");
HttpWebRequest HttpWRequest = (HttpWebRequest)WebRequest.Create(_uri);
HttpWRequest.Method = "POST";
clfLogMsg(f, "Method = " + HttpWRequest.Method.ToString());
HttpWRequest.KeepAlive = true;
clfLogMsg(f, "Keep Alive = " + HttpWRequest.KeepAlive);
HttpWRequest.Timeout = 300000;
clfLogMsg(f, "Timeout = " + HttpWRequest.Timeout);
HttpWRequest.ContentType = "application/x-www-form-urlencoded";
clfLogMsg(f, "Content Type = " + HttpWRequest.ContentType);
byte[] PostData = System.Text.Encoding.ASCII.GetBytes(parameters);
Stream tempStream = null;
bool returnval = false;
try {
clfLogMsg(f, "Setting Conecnt Length");
HttpWRequest.ContentLength = PostData.Length;
clfLogMsg(f, "HttpWRequest.GetRequestStream()");
tempStream = HttpWRequest.GetRequestStream();
clfLogMsg(f, "Stream write");
tempStream.Write(PostData, 0, PostData.Length);
clfLogMsg(f, "Stream written");
returnval = true;
}
catch (Exception ex) {
clfErrorHandler("Exception", f, "WebException happened writing request", ex.Message);
}
finally { if (tempStream != null) { tempStream.Close(); } }
tempStream = null;
return returnval;
}
Eigentlich alles "by the book" wie man so schön sagt.
Funktioniert die ersten drei mal auch wunderbar.
Ab dem dritten bis vierten Aufruf fangen die Probleme an.
Die Funktion läuft durch und bleibt dann beim GetRequestStream() hängen.
tempStream = HttpWRequest.GetRequestStream();
Anhand der Logs sehe ich auch schwarz auf weiß wie lange das Ding hängt.
DebugView Log ::
(26.09.2008 14:12:44) : clfAcceptMediaCall() :: Function called
(26.09.2008 14:12:44) : clfHttpPost(...) :: Function called
(26.09.2008 14:12:44) : clfHttpPost(...) :: - Parameters = mid=11667
(26.09.2008 14:12:44) : clfHttpPost(...) :: - Uri = [URL]http://10.3.2.144/cgi_bin/web2tr/read[/URL]
(26.09.2008 14:12:44) : clfHttpPost(...) :: Creating HttpWRequest
(26.09.2008 14:12:44) : clfHttpPost(...) :: Method = POST
(26.09.2008 14:12:44) : clfHttpPost(...) :: Keep Alive = True
(26.09.2008 14:12:44) : clfHttpPost(...) :: Timeout = 300000
(26.09.2008 14:12:44) : clfHttpPost(...) :: Content Type = application/x-www-form-urlencoded
(26.09.2008 14:12:44) : clfHttpPost(...) :: Setting Conecnt Length
(26.09.2008 14:12:44) : clfHttpPost(...) :: HttpWRequest.GetRequestStream()
< - hier ist der zeitunterschied - >
(26.09.2008 14:17:17) : clfHttpPost(...) :: Stream write
(26.09.2008 14:17:17) : clfHttpPost(...) :: Stream written
TdiMon Log ::
2726 14:17:16 TestUi: 81CACBA0 TDI_QUERY_INFORMATION TCP:0.0.0.0:2491 Query Address
Query Address SUCCESS
2727 14:17:16 TestUi: 8200FBF8 IRP_MJ_CREATE TCP:Connection obj Context:0x824AC328
Context:0x824AC328 SUCCESS
2728 14:17:16 TestUi: 8200FBF8 TDI_ASSOCIATE_ADDRESS TCP:Connection obj TCP:0.0.0.0:2491
TCP:0.0.0.0:2491 SUCCESS
2729 14:17:16 TestUi: 8200FBF8 TDI_CONNECT TCP:0.0.0.0:2491 10.3.2.144:80
10.3.2.144:80 10.3.2.144:80 SUCCESS
2730 14:17:16 TestUi: 8200FBF8 TDI_SEND TCP:0.0.0.0:2491 10.3.2.144:80 Length:170
Length:170 SUCCESS
2735 14:17:17 TestUi: 8200FBF8 TDI_SEND TCP:0.0.0.0:2491 10.3.2.144:80 Length:9
2736 14:17:17 TestUi: 81CACBA0 TDI_EVENT_CHAINED_RECEIVE TCP:0.0.0.0:2491 10.3.2.144:80
10.3.2.144:80 PENDING Length:83 Flags: ENTIRE_MESSAGE LOOKAHEAD DISPATCH
Length:83 Flags: ENTIRE_MESSAGE LOOKAHEAD DISPATCH SUCCESS-2737
Das sind gute 5 Minuten in dem nichts passiert bis die Verbindung erst aufgebaut wird und such die Daten geschrieben werden.
Danach geht es wieder zwei bis drei mal normal, flott wie gewünscht und dann hängt es wieder für ein mal.
Ich verstehe eigentlich gar nicht wieso dass passiert.
Resourcenengpass? Wo genau aber?
Wie gesagt, es liegt irgendwo am
tempStream = HttpWRequest.GetRequestStream();
Habt Ihr eventuell ne gute Idee ?
Danke im Vorraus.
Gruß.
mv sig /dev/null
Tach!
Idee habe ich leider keine - aber da ich das selbe Problem habe bin ich auch grade am suchen.
Hast du schon eine Lösung?
Bei mir kommt noch die Eigenart dazu, dass ich drei Mobile-Projekte habe und dazu drei Web-Applikationen aber nur bei einem habe ich das Problem...
Der entsprechende Source-Teil ist bei allen Mobile-Programmen und den Web-Applikationen genau der gleiche...???
lg
//Edit: Mit Mobile-Projekt meine ich übrigens .NET CompactFramework auf einem WM6 Gerät...
Programmieren ist der Wettkampf zwischen Programmierer die immer noch einfachere Programme schreiben
und Anwender die immer noch dümmer werden...
🙂
Wenn nur alles so einfach wäre... Hab eine Zeile vergessen...
ResponseStream und Response einfach immer mit Close() schließen und dann tritt das ganze (zumindest jetzt bei mir) nicht mehr auf...
lg
Programmieren ist der Wettkampf zwischen Programmierer die immer noch einfachere Programme schreiben
und Anwender die immer noch dümmer werden...