Laden...

DLL friert während HttpWRequest.GetRequestStream() kurzweilig ein

Erstellt von stacato vor 15 Jahren Letzter Beitrag vor 15 Jahren 1.159 Views
S
stacato Themenstarter:in
1 Beiträge seit 2008
vor 15 Jahren
DLL friert während HttpWRequest.GetRequestStream() kurzweilig ein

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

W
201 Beiträge seit 2007
vor 15 Jahren

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...

W
201 Beiträge seit 2007
vor 15 Jahren

🙂
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...