Mehrfachausführung eines CGI

[Lemmy]

Hallo,

CGI mit Delphi 7, läuft unter IIS (Windows Server 2003). Laufzeit ist teilweise über eine Stunde (Datenimport).

Nun ist es so, dass genau nach einer Stunde eine weitere Instanz der CGI startet, ohne dass der Anwender am Browser (IE) irgend etwas unternimmt (festgestellt durch die Protokollierung in einer Datenbank).

Ich bin jetzt hergegangen und habe in das CGI einen Mutex eingebaut, der die Mehrfachausführung unterdrücken soll. Wenn ich das in der Konsole teste funktioniert das wunderbar. Wenn ich im Browser 2 Tabs öffne und in jedem das CGI kurz nacheinander starte passiert folgendes: Der erste CGi-Aufruf wird abgearbeitet und so lange der läuft wird der Aufruf des zweiten Registers "zurückgehalten". Erst wenn der Lauf des CGI im Tab1 fertig ist, startet der CGI Aufruf des zweiten Tab!

Nur wenn ich innerhalb eines Tab das CGI kurz nacheinander starte erhalte ich die gewünschte Fehlermeldung. Das würde mir erst mal für die Geschichte oben ausreichen, dennoch wüsste ich gerne woher das Verhalten mit den beiden Tabs kommt.

Hat jemand von euch nen Plan was da abgeht? Ach ja: Das Verhalten kann ich so auch unter Apache (2.2) und anderen Browsern nachvollziehen.

Danke
Lemmy

[sx2008]

Das ist doch bei CGI ganz normal dass es mehrere Instanzen der gleichen CGI.exe geben kann.

Zitat:

und habe in das CGI einen Mutex eingebaut, der die Mehrfachausführung unterdrücken soll

Was stört dich an den mehreren Instanzen?
Dein Mutex begrenzt die Skalierbarkeit.

[Lemmy]

Hi,

generell hast Du natürlich recht, allerdings geht es hier wie oben beschrieben um ein CGI das einen Datenimport durchführt. Und wenn man den mehrfach mit den selben Daten auf der selben Datenbank ausführen lässt, dann wird die Performance davon eher negativ beeinträchtigt.
deshalb soll das Teil auf einer Datenbank eben nur einmal zur selben Zeit laufen.

Grüße

[nahpets]

Hallo,

ich gehe davon aus, dass der Mutex nur innerhalb der Session gültig ist, in der das CGI-Programm gestartet wurde. Hast Du zwei Tabs, sind es (vermutlich) zwei Sessions, die sich untereinander nicht sehen.

Das ist jetzt zugegeben nur reines Spekulatius von mir.

Alternative Lösung:

Das CGI schreibt in eine Datei, Datenbank... hinein, dass es läuft und entfernt diesen Eintrag beim Beenden. Beim Start prüft es zuerst, ob es diesen Eintrag gibt, wenn ja, beendet es sich (mit entsprechender Meldung als HTML-Seite?).

Auf die Existenz einer Datei zu prüfen, dürfte hier die "billigste" Lösung sein, da nur ca. 3 bis 5 Zeilen Quelltext erforderlich sind.

Problem dabei:

Sollte das Programm sich mal nicht korrekt beenden, bleibt der Eintrag bestehen und es erfolgt kein erneuter Start des Programmes, bis eine manuelle Bereinigung erfolgte.

Dieses Problem kann aber auch bei funktionierendem Mutex auftreten, wenn das Programm diesen zwar setzen kann, aber dann abraucht. Der Mutex bleibt auch dann bestehen.

In dem Fall ist das Wegräumen einer überflüssigen Datei aber einfacher.

[Lemmy]

Zitat:

Zitat von nahpets (Beitrag 1220948)

Hallo,

ich gehe davon aus, dass der Mutex nur innerhalb der Session gültig ist, in der das CGI-Programm gestartet wurde. Hast Du zwei Tabs, sind es (vermutlich) zwei Sessions, die sich untereinander nicht sehen.

Ok, was aber nicht erklärt weshalb im zweiten Tab die Ausführung des CGi solang angehalten wird, bis das cgi im ersten Tab fertig ist. Vielleicht noch zur Klarstellung: Das passiert auch ohne einen aktiven Mutex-Code!

Dein Vorschlag über eine Lock-Datei bzw. Eintrag in einer Datenbank wäre in dem Fall eine gute Lösung. Die Nachteile sind mir so weit bekannt.

Grüße

[nahpets]

Zitat:

Zitat von Lemmy (Beitrag 1220949)

Ok, was aber nicht erklärt weshalb im zweiten Tab die Ausführung des CGi solang angehalten wird, bis das cgi im ersten Tab fertig ist. Vielleicht noch zur Klarstellung: Das passiert auch ohne einen aktiven Mutex-Code!

Könnte es sein, dass der/die Webserver ein CGI-Programm nicht zeitgleich zweimal laufen lassen?
Oder dass das zweite CGI-Programm nicht auf die Datenbank zugreifen kann und deshalb wartet?
Ersteres müsste dann auch passieren, wenn Du eine dateibasierte "Doppeltenprüfung" implementierst, was dann für Deine Problemlösung leider kontraproduktiv wäre.
Ist die Datenbank das Problem, müssten auch mehrere CGI-Programme gleichzeitig laufen können, da weitere CGI-Programm ja nicht mehr auf die Datenbank zugreifen.

Wenn das erste CGI-Programm läuft, sind dann weitere Zugriffe, die nicht eine zweite Instanz das CGI-Programmes betreffen, möglich? Oder blockiert das erste CGI-Programm den Webserver?

Gleiches Verhalten, wenn das erste CGI-Programm aus dem IE angetriggert wird und das zweite aus dem Firefox? Oder tritt das "Phänomen" nur auf, wenn mehrere Aufrufe über mehrere Tabs eines Browsers erfolgen? Kannst Du die Aufrufe des CGI-Programmes im Log der Webserver sehen? Oder erscheint der zweite Aufruf dort erst, wenn das erste Programm beendet wurde?

Wenn ich das recht beobachtet habe, lassen Browser (protokollbedingt?) nur eine begrenzte Anzahl von Zugriffen auf einen Webserver zeitgleich zu, ist also sicher, dass der zweite Aufruf des CGI-Programmes beim Webserver ankommt, bevor das erste CGI-Programm beendet wurde?

[Phoenix]

Hilft zwar nicht bei der konkreten Frage, aber ich habe eine eigene Frage dazu:

Warum macht ein Programm im IIS-Kontext den Datenimport?
Der IIS ist ziemlich unberechenbar wann er Prozesse spawned, terminiert (je nach Timeout-Setting) etc. Es kann Dir gut passieren dass bei der Entwicklung alles sauber läuft und im Produktionsbetrieb durch irgend einen anderen Patchlevel des IIS der Prozess immer nach X Minuten terminiert wird.

Ich würde Import-Anfragen in der DB als Queue ablegen und einen separaten Service laufen lassen der die eigentliche Arbeit macht. Ggf. mit Informationen zum Fortschritt des Imports auch in der DB, so dass wenn ein Browser das anstösst dieser über den aktuellen Status des Imports informiert werden kann.

Wenn eh schon eine IIS-Anwendung installiert werden muss, dann wäre ein zusätzlicher Service sicher auch noch zu verkraften. Zudem kannst Du so 100% sicher sein das immer genau nur eine einzige Instanz des Services läuft wenn auch nur eine installiert ist.

[nahpets]

@Phonix

da hast Du sicherlich recht. Einen Langläufer über den Browser anzusteuern, halte ich auch nicht unbedingt für optimal.

Wenn aber schon per Browser der "Startschuss" gegeben werden soll, so könnte man ja hier einen Service bauen, der (z. B. mit den Indy-Komponenten) einen kleinen Webserver darstellt. Er benötigt dann halt einen eigenen Port für den Zugriff, könnte seine Antworten selbst ausliefern und muss keine aufwändige Prüfung machen, ob schon ein Import läuft, da er es ja selbst macht und von daher "weiß", wann er importiert.

Was passiert eigentlich mit einem CGI-Programm, wenn man den Browser schließt, während das Programm läuft?
Bei meinem Webserver kann ich konfigurieren, wielange ein CGI-Programm laufen darf, bevor es vom Webserver (zwangsweise) beendet wird. Gibt es diese Konfigurationsmöglichkleit auch beim IIS und beim Apache?
Wenn ja, so müsste man ja sicherstellen, dass die Konfiguration so erfolgt, dass dieses CGI-Programm quasi beliebig lang laufen darf. Sofern man das Timeout nicht für jedes CGI-Programm separat konfigurieren kann, würde man damit ja auch die mögliche Laufzeit für alle CGI-Programme hochsetzen, auch für die, bei denen eine Antwort eher in Sekunden erwartet wird. Dies halte ich nicht für eine besonders gelungene Lösung.

Wenn das Programm nach einer Stunde ein zweites Mal gestartet wird, könnte das eventuell damit zusammenhängen, dass den Webservern die "Wartezeit" auf das Ende des Programmes zu lange wird und sie es daher nochmal starten (quasi ein Timeout von einer Stunde mit automatischem Neustart des CGI-Programmes)?

[sx2008]

Fast-CGI wäre die optimale Lösung für das Problem.
Leider scheint es ziemlich schwierig für Delphi eine entsprechende Fast-CGI Lib zu finden.

[Lemmy]

Zitat:

Zitat von nahpets (Beitrag 1220963)

Wenn das Programm nach einer Stunde ein zweites Mal gestartet wird, könnte das eventuell damit zusammenhängen, dass den Webservern die "Wartezeit" auf das Ende des Programmes zu lange wird und sie es daher nochmal starten (quasi ein Timeout von einer Stunde mit automatischem Neustart des CGI-Programmes)?

davon geh ich aktuell aus: da keine Antwort erfolgt, fragen wir halt einfach nochmal nach. Interessant wäre es noch ob man das Verhalten auch konfigurieren kann.

@Phoenix:
Weshalb das CGI den Datenimport macht kann ich so auch nicht wirklich erklären - Ich habe das Projekt erst vor kurzem übernommen, das läuft schon etliche Jahre so und ist auch recht zuverlässig - sonst hätte man das schon längst geändert - aber mal schauen was die Zukunft so alles bringt...