WebModule & ADOConnection in Service -> Speicherübrelauf

[nahpets]

Meine letzten Webmodule sind schon 'ne Weile her, daher nur so aus dem Gedächtnis:

ADO-Komponenten habe ich auf das Webmodul gepappt. Sie werden beim Create des Webmoduls erstellt und beim Destroy wieder weggeräumt.

Habe sie also nicht bei jeder Anfrage an den Server erstellt und nach erledigter Arbeit freigegeben. Allerdings weiß ich nicht, inwieweit dieses mein Vorgehen threadsave ist.

Dein Vorgehen könnte da durchaus sinnvoller sein.

Wenn Du nur eine ADOQuery nutzt, benötigst Du keine ADOConnection, es reicht, wenn die ADOQuery den Connctionstring erhält.

Das CoInitialize(nil); und das CoUninitialize; stecken bei mir am Ende der Unit unter:

Delphi-Quellcode:

initialization
  CoInitialize(nil);

finalization
  CoUninitialize;

end.

Sie müssen nicht bei jeder Anfrage an den Server aufgerufen werden.

Ansonsten hab' ich an Deinem prinzipiellen Aufbau des Webmodules nix auszusetzen, allerdings solltest Du eventuell bei Methoden wie

Delphi-Quellcode:

procedure TWebModuleMain.tcmGet(Request: TWebRequest;
  Response: TWebResponse);

noch 'nen Try-Except-Block einfügen, damit Du bei Fehlern eine gescheite Fehlermeldung an den Client schicken kannst. Es muss sichergestellt sein, dass alles das, was Du in der Methode Send501 befüllst, immer gefüllt ist und (egal was passiert) am Ende ein erfolgreiches Response.SendResponse; steht. Ansonsten kann es passieren, das Webserver und/oder Client irgendwann ins Stolpern geraten. Und dann den Fehler suchen müssen, ist nicht wirklich spaßig.

[markusef]

Okay, ja ein vernünftiges Exception Handling muss da definitiv noch rein, da hast du recht.
Das Daten abfragen mit der ADOQuery funktioniert auch so einwandfrei, Danke für den Tipp, das spart Quelltext.

Allerdings ist das Problem leider noch nicht behoben, mit jeder Anfrage steigt die Arbeitsspeicherauslastung des Services echt enorm, sinkt aber nach beendigung aller Anfragen auch nicht mehr

Woran kann das denn noch liegen ?
Könnte es sein das man die Webmodule nicht in einem Windows Service benutzen sollte ?

Habe mir da schon die Finger wund-gegooglet und überall werden die Webmodule nur in .dlls für IIS oder Apache genutzt

*EDIT:

CoInitialize(nil) & CoUni.. kann ich leider nicht in den jeweiligen Part für "initialization" und "finalization" packen, dann wirft mir Delphi vor ich hätte CoInitialize nicht aufgerufen :-/

*EDIT EDIT:

Grundlegende Frage: Wird, wenn sich ein Client mit dem Service verbindet, je Client ein WebModule Instanz erzeugt ? Oder pro Anfrage (auch vom selbem Client, weis ja nicht ob die Delphi Komponente sich das merkt) ?
Falls ja, wieso wird nachdem der RESTClient expliziert Disconnect aufruft die jweilige Instanz nicht abgeschossen ?

[Jumpy]

Hast du mal geschaut, ob vllt. bei jeder Request ein neues Webmodul erstellt wird? Wenn du das nicht so verwendest, wie es gedacht ist, könnte das doch sein?

OK, hast in deinem EditEdit ja die selbe Idee Edith

Vllt. zeigst du uns mal den Code des Services, wo das Webmodul eingebettet ist?

[Jumpy]

Zitat von Jumpy:

Vllt. zeigst du uns mal den Code des Services, wo das Webmodul eingebettet ist?

Wie siehts denn damit aus? Vielleicht liegt es ja am drum herum (plus die ADO-Komponenten)?

[markusef]

"Nochmals" war schon richtig, hatte die Idee mit der initialization / finalization bereits probiert, leider funktioniert es dort nicht.
Werde es jetzt nochmal direkt in der .dpr testen, sprich den von dir geschilderten Ablauf, andernfalls werde ich mir die .dll mal zu gemüte führen, schon mal ein riesen Danke im voraus !!!

An dem "drumherum" kann es nicht liegen da es ohne die ADOConnection problemlos läuft und kein Arbeitsspeicherüberlauf eintritt, das ist ja das verwunderliche, zumal ich die ADOConnection so gut wie immer verwende und das immer in diesem Service-Template (man tippt ja ungern doppelt ), nur eben zum ersten mal mit einem WebModule

Werde mich dann mit weiteren Infos melden wenn es Neuigkeiten gibt.
Danke für eure Hilfe bis jetzt

[nahpets]

Meckert Delphi auch noch, wenn Du die beiden Co...Dingens ins Create bzw. Destroy packst?

Bei mir (mit Delphi 7) gab es von Delphi immer schimpfe, wenn ich es nicht bei "initialization" und "finalization" reingepackt hatte, sondern sonstwo.

Habe Webmodule nur in DLLs und CGIs für meinen Webserver genutzt. Ob das in 'nem Service nicht nutzbar ist, weiß ich nicht.
Aber eigentlich ist Dein Service doch das gleiche wie 'ne Exe plus DLL in "eins zusammengepackt"

Beim fünften mal Lesen Deines Quelltextes fiel mir was auf, weiß aber nicht, ob das Problem daher kommen könnte:

Auf ein ADOQuery.Open folgt kein ADOQuery.Close.

[markusef]

Also anscheinend wird beim erstmaligen verbinden eine Instanz von TWebModule angelegt, danach (vorerst) keine weitere. Ich habe einen Testclient gebaut welcher eine Anfrage schickt, auf ein Response wartet und wenn ein Response ankam gleich den nächsten Request abschickt. Dann rutschte er zu Beginn zwei mal in die WebModuleCreate und anschließend lief alles im Alleingang (hatte beim Debugen nur einen Haltepunkt in der Create und in der Destroy), Destroy wurde auch erst bei Beendigung des kompletten Services ausgeführt.
Irgendwas ist da mächtig Faul

CoInitialize(nil) und CoUnitialize war auch mein nächster Tipp im Create, das funktioniert auch, komischerweise aber nur bis zu einem bestimmten Punkt, ab einer gewissen Anzahl von Anfragen wirft er mir plötzlich trotzdem eine Exception das CoInitialize nicht aufgerufen wurde.

ADOQuery.Close verhalf leider auch nicht zum gewünschten Erfolg :-/

[nahpets]

Das wird jetzt irgendwie etwas seltsam:

Jetzt kommt von mir mal nur vermuteter Spekulatius ohne Gewähr.

Meine mal gelesen zu haben, dass pro Client ein Webmodul erstellt wird. Also müsste pro Client auch einmal Create aufgerufen werden.

Bei der Verwendung von HTTP können (meine ich jedenfalls) zwischen einem Client und einem Server zwei Verbindungen aufgebaut werden. Dies würde das zweimalige Aufrufen von Create bei Nutzung eines Testclients erkären.

Was passiert, wenn Du den Testclient mehrfach startest. Erhöht sich die Anzahl der Create-Aufrufe dann?

Wenn ja, dann packe die ADOQuery mal auf das Webmodule, statt sie bei 'ner Anfrage selbst zu erstellen und wieder freizugeben.

Wird das Webmodule pro Client erstellt, dürfte es dann auch (kaum) zu Konflikten kommen, wenn mehrere Anfragen unterschiedlicher Clients zeitgleich beim Service ankommen.

Das mit dem CoIni-Dingens kann ich (nicht) verstehen.

Wenn das für die ganze Applikation gilt, dürfte bei wiederholten Anforderungen an den Service mit jeweiligen Aufrufen von CoInitialize und CoUninitialize und gleichzeitigen Anfragen mehrere Clients hier ein bisserl "Durcheinander" entstehen. Es ist ja nicht sichergestellt, dass die Anfragen vollständig nacheinander "abgearbeitet" werden.

Habe bei meinen ISAPI-Dlls erst dann Ruhe gehabt, nachdem ich die Aufrufe nach initialization bzw. finalization verschoben hatte.

Mal noch 'ne andere Idee:

Kannst Du die beiden Aufrufe nicht irgendwo außerhalb des Webmoduls im Service unterbringen?

Oder, nachdem ich mal in alte Quellen geguckt habe, in der DPR zu eine ISAPI-Dll steht dashier:

Delphi-Quellcode:

library WebSQLSearch;

uses
  ActiveX,
  ComObj,
  ISAPIThreadPool,
  ISAPIApp,
  BrkrConst in '..\..\..\Delphi7\Source\Internet\BrkrConst.pas',
  WebBroker in '..\..\..\Delphi7\Source\Internet\WebBroker.pas',
  WebSQLSearchUnit1 in 'WebSQLSearchUnit1.pas' {wm: TWebModule};

{$R *.res}

exports
  GetExtensionVersion,
  HttpExtensionProc,
  TerminateExtension;

begin
  CoInitFlags := COINIT_MULTITHREADED; // <--- Hast Du das irgendwo untergebracht?
  Application.Initialize;
  Application.CreateForm(Twm, wm);
  Application.Run;
end.

Eventuell bekommst Du das Problem ja dann hiermit weg:

Delphi-Quellcode:

initialization
  CoInitFlags := COINIT_MULTITHREADED;
  CoInitialize(nil);

finalization
  CoUninitialize;

end.

[HolgerX]

Hmm..

Hab noch kein Webmodul erstellt, also in blaue...

Wenn dein

getNothing(

in seinem eignen Thread aufgerufen wird, dann muss immer das CoInitialize und das CoUninitialize im getNothing( gemacht werden, sprich da , wo mit den ADOs gearbeitet wird!

Jeder Thread muss sein eigenes CoInitialize machen, deshalb geht das (globale) CoInitialize im Initialization nicht.

[nahpets]

Mein praktische Erfahrung mit dutzenden von ISAPI-Dlls ist bisher: Es geht nur, wenn es so

Delphi-Quellcode:

initialization
  CoInitialize(nil);

finalization
  CoUninitialize;

end.

gemacht wurde und in der DPR die erste Zeile hinter dem begin   CoInitFlags := COINIT_MULTITHREADED; lautet.

Habe jedenfalls in meinem Fundus keine funktionierende ISAPI-Dll bzw. kein funktionierendes CGI-Programm, die/das ADO nutzt und der Aufruf anders geregelt ist.