WebModule & ADOConnection in Service -> Speicherübrelauf

[HolgerX]

Hmm..

Zitat:

Zitat von nahpets (Beitrag 1358938)

CoInitialize(nil) und CoUninitialize dürfen nur einmalig aufgerufen werden. Nicht pro Verbindung und nicht pro Client und nicht pro Anfrage, sondern insgesamt nur einmal.

Nicht ganz richtig..

Lt.:

https://msdn.microsoft.com/de-de/lib...(v=vs.85).aspx

MUSS CoInitialize(nil) und CoUninitialize JE Thread aufgerufen werden wenn COM verwendet werden soll, was bei ADO nun mal so ist.

Wenn jede Anfrage über das WebModule in einem eigenen Sub-Thread ausgeführt wird, muss auch in der Execute des Threads CoInitialize(nil) und CoUninitialize aufgerufen werden.

Auch kannst Du mehrfach CoInitialize aufrufen, musst nur jeweils auch ein CoUninitialize dazu machen.

Ob es bei einer ISAPI-Dll anders ist, oder ob diese DLL immer nur aus einem Thread (MainThread) aufgerufen wird.. k.A.

Jedoch deuten die Fehlermeldungen von seinem ADO-Aufruf darauf hin, dass diese in einem eigenen Thread aufgerufen werden und somit expliziert CoInitialize brauchen.
Warscheinlich sind die ADOs eben nicht ThreadSave und somit eventuell von CoInitFlags := COINIT_MULTITHREADED ausgenommen..

[nahpets]

Also den Fehler mit dem CoIni ... nicht aufgerufen hab' ich bei den ISAPI-Dlls erst dann wegbekommen wenn ich

1. ISAPIThreadPool in die Uses der DPR
2. CoInitFlags := COINIT_MULTITHREADED hinter das Begin der DPR
3. CoInitialize(nil); ins initialization des Webmoduls
4. CoUninitialize; ins finalization des Webmoduls

gepackt habe.

Und ja, es widerspricht allen Dokumentationen.

[HolgerX]

Hmm..

Zitat:

Zitat von nahpets (Beitrag 1359010)

Also den Fehler mit dem CoIni ... nicht aufgerufen hab' ich bei den ISAPI-Dlls erst dann wegbekommen wenn ich

1. ISAPIThreadPool in die Uses der DPR
2. CoInitFlags := COINIT_MULTITHREADED hinter das Begin der DPR
3. CoInitialize(nil); ins initialization des Webmoduls
4. CoUninitialize; ins finalization des Webmoduls

gepackt habe.

Und ja, es widerspricht allen Dokumentationen.

OK, dann sollte er mal prüfen, ob er es genau so gemacht hat.
Vielleicht kümmert sich ja die ISAPIThreadPool dann um die COM-Verwaltung ?!?

[nahpets]

Das Teil ISAPIThreadPool ist irgendwie dafür verantwortlich, dass das Multithreading in 'nem Webserver mit ISAPI-Dlls überhaupt funktioniert.

Und hier wird im konkreten Fall ja eine Webserver erstellt, der mehrere Anfragen von mehreren Clients zeitgleich verarbeiten können muss.

Eventuell sollte man sich die Unit mal genauer anschauen und prüfen, was dort so alles geschieht, was im zu erstellenden Service (und seinen genutzten Units) nicht vorhanden ist.

CoInitializeEx und CoUninitialize werden in der Unit u. a. auch aufgerufen.

[markusef]

Neuer Stand:

ich werde das ganze Projekt jetzt doch als .dll für einen IIS aufbauen. Bezüglich der ADO/Webmodule/Service-Geschichte gab es einfach keine Fortschritte und auch (aus meiner Sicht) keine Anhaltspunkte mehr um das ganze Zeitnah zu realisieren.

Mit der .dll unter IIS funktioniert das einwandfrei, danke an der Stelle nochmal an naphets, das war ein super Beispiel zum orientieren ! :thumb:
Ist zwar jetzt ein wenig umständlicher zu handhaben, aber es geht zumindest und das auch sehr performant !

Wenn mal wieder Luft ist werde ich natürlich weiter versuchen das ganze als Service zu realisieren (sowas kann man ja nicht auf sich beruhen lassen :-P).
Falls euch noch was einfallen sollte, ich werde den Thread dennoch regelmäßig besuchen & updates geben wenn ich an der Problematik weiter getüfftelt habe :)

[markusef]

Also mit der .dll klappt das soweit wunderbar.
Allerdings wächst der Arbeitsspeicher für die w3wp.exe die die isapi dll nutzt pro Anfrage auch ziemlich schnell ins unermessliche. Nachdem ich die Verbindung des Clients beende bleibt die w3wp.exe einfach bei der Größe stehen und es passiert auch nichts weiter.
Irgendwo mache ich demnach etwas falsch, ich weis aber beim besten Willen nicht was.

Muss ich noch dafür sorgen das die WebModule Threads nach abarbeitung beendet werden ? Ich dachte eigentlich das die Threadverwaltung vom IIS Manager übernommen wird

[nahpets]

Das wird jetzt schwierig, da ich mit dem IIS keinerlei Erfahrung habe. Habe meinen eigenen Webserver (mit den Indy-Komponenten) erstellt. Mit dem nutze ich seit Jahren Isapi-Dlls, auch solche, die ADO nutzen. Habe dort bisher keinen Speicherzuwachs feststellen können. Die DLLs sind alle so aufgebaut, wie in meinem Beispiel. Es gibt also nichts zum Aufräumen ...

Frage: Musst Du ADO nutzen?

Hast Du schonmal mit den Zeos-Komponenten gearbeitet?
Dort kann man auch die ADO-Schnittstelle nutzen.
(Zuletzt hier http://www.delphipraxis.net/191453-z...ml#post1359230 behandelt.)

Bleibt mit denen das Problem erhalten? Wenn nein, würde ich es in den ADO-Komponenten suchen und auf Zeos wechseln.

Eine (langsamere) Alternative:

Erstelle bitte eine neue CGI-Anwendung.
Entferne aus dieser das Webmodul.
Füge das Webmodul Deiner ISAPI-Dlls hinzu.
Im Idealfall hast Du nun (ohne weitere Änderungen) eine CGI-Anwendung mit identischem Funktionsumfang.

Kannst Du diese mit dem IIS nutzen?
Ändert sich etwas, außer dem Laufzeitverhalten?

Was ändert sich bei der w3wp.exe und/oder dem IIS noch?
Neben dem Speicherverbrauch, Handles? Threads? Benutzerobjekte?
Gibt es in der DLL eventuell Speicherlöcher?

Liefert Dir der https://www.heise.de/download/produc...explorer-21841 eventuell genauere Informationen.

Könntest Du bitte den aktuellen Quellcode Deiner momentanen Fassung (dpr und pas) hier posten? Eventuell kann man ja was sehen.
Je nach Umfang könnte ich mal schauen, ob ich sie auf eine eigene Datenbank umkonfigurieren kann und dann mal mit meinem Webserver testen.

Sind hier eventuell hilfreiche Informationen zur Problemlösung zu finden?
http://help.sap.com/saphelp_nw73ehp1...a/frameset.htm

Eine weitere Frage, eher mal so in den Raum geworfen, in der Hoffnung, dass irgendwer aus dem Forum sie beantworten kann:

Der Zugriff auf MaxDB von SAP ist per ODBC, JDBC, SQLDBC (http://open-maxdb-group.org/components/interfaces/) möglich. Welche Zugriffsmöglichkeiten gibt es hier bei aktuellen Delphis, ohne über die ADO-Schnittstelle zu gehen? Gibt es sie überhaupt?