![]() |
SOAP-Bombardement
Hi Community!
Ich habe vor einiger Zeit eine SOAP-Server-Anwendung mit inzwischen 3 versch. zugehörigen Clients erstellt. Der Server besteht aus 5 Units: 1. Implementation-Unit 2. Interface-Unit 3. WebModule + Unit 4. und 5. sind eigene Units mit Funktionen und Prozeduren, die von den Server-Methoden benutzt werden Mein Problem ist: Ich weiß nicht genau, wie Delphi intern mit mehreren "gleichzeitig" ankommenden Client-Aufträgen umgeht. Werden dafür Threads generiert? Wenn ja, müsste es beim Aufruf der Funktionen/Prozeduren der Units 4 und 5 zu Problemen kommen, da ich kein Synchronize verwende. Aber synchronize benutzt man ja nur, um (selber generierte) Threads mit dem Hauptthread zu synchronisieren. Ich habe ja aber keinen Hauptthread in dem Sinne.. Auch das Schreiben in ein und das gleiche LogFile müsste zu Konflikten führen.. Um das zu testen habe ich den Server mal bombardiert: Habe 20 mal eine 117MB große Datei geschickt, 20 mal eine 85MB große Datei und 50 mal eine 11MB große Datei. Dabei ist zwar nicht gesagt, dass Konflikte, die evtl. auftreten könnten, tatsächlich auftreten, aber mir schien es ein gutes Test-Scenario zu sein. Der Test endete damit, dass der IIS abgeschmiert ist, weil er alle ankommenden SOAPAttachments in ein auf C: liegendes Temp-Verzeichnis ablegt, diese dort aber niemals löscht.. Neustarten ließ sich der IIS nach dem Bereinigen der Platte auch nicht, so dass mein Test eine Neuinstallation des IIS nach sich zog, mir aber keine Informationen geliefert hat.. Alternativ könnte ich mir auch vorstellen, dass der Server auf dem spezifizierten Port lauscht und wenn etwas kommt, einen Prozess von sich selbst startet. Kommen also 10 Client-Aufträge rein, werden 10 Server-Prozesse meines Servers gestartet, so wie wenn man beispielsweise Delphi 2 mal startet. Dann würden Aufrufe der Funktionen/Prozeduren der Units 4 und 5 kein Problem darstellen, sondern nur die Speicherung des Logs in der gleichen Datei. Wenn dem so ist, dann müsste ich die Prozesse ja im Taskmanager des Rechners, auf dem der IIS installiert ist, sehen, oder? Werde darauf mal achten, sobald der IIS wieder flott ist. Vielleicht funktioniert das intern aber auch ganz anders? Die Funktionen und Prozeduren, die der Server dem Client zur Verfügung stellt, sind ja Methoden einer Klasse. Diese Klasse wird vom Client instanziert, um die Methoden benutzen zu können. D.h. jeder Client-Auftrag läuft im Endeffekt mit einer anderen Instanz der Server-Klasse. Aber im Endeffekt klingt das auch wieder nach Threads.. Die Frage ist halt, wie ich Konflikten vorbeuge, etwa wo ich CriticalSections benutze etc Also Frage zusammengefasst: 1 Client-Auftrag = a) 1 neuer Thread b) 1 neuer Prozess der Server-Applikation c) etwas ganz anderes Ich hoffe, ich konnte mich einigermaßen verständlich ausdrücken. mfg hyype |
Re: SOAP-Bombardement
ok, gehen wir mal davon aus, es wären prozesse, wie krieg ich es dann hin, dass diese nicht gleichzeitig ins logfile schreiben?
habe gedacht, sowas geht mit einem semaphore, aber wenn der eine prozess ein semaphore erzeugt, weiß doch der nächste nichts davon. und wird der prozess beendet, ist das semaphore doch auch weg, oder? es verwirrt mich auch, dass hier im forum über semaphoren nur im zusammenhang mit threads gesprochen wird, da ich dachte, dass man mit synchronize und criticalsections wunderbar threads handlen kann das problem ist, dass ich, wenn die annahme mit den prozessen stimmt, kein hauptprogramm habe, wo ich global ein semaphore definieren könnte, so dass es jeder benutzen kann edit: Der IIS ist nach wie vor tot, alle Wiederbelebungsmaßnahmen schlugen fehl, am Montag bringt der Admin einen Neuen auf diese Welt. ^^ Ich habe mal ein Semaphore eingebaut:
Delphi-Quellcode:
Ich habe auch verstanden, dass, wenn mehrere Prozesse CreateSemaphore mit dem gleichen Namen aufrufen, alle Prozesse nach dem 1. das Handle des im 1. erzeugten Semaphore erhalten. Und wenn kein Prozess das Handle mehr benutzt, wird der Semaphore freigegeben. Eigentlich genial!
initialization
semaphore:=CreateSemaphore(nil, 1, 1, 'hypersemaphore'); finalization CloseHandle(semaphore); Benutzung: if sl.Count>0 then begin if semaphore>0 then //andernfalls hat createsemaphore nicht geklappt begin if WaitForSingleObject(semaphore, 5000) = WAIT_OBJECT_0 then //andernfalls hat wfso nicht geklappt begin log; ReleaseSemaphore(semaphore, 1, nil); end; end; end; Nur wenn das SemaphoreHandle nicht größer 0 ist (CreateSemaphore fehlgeschlagen) oder waitforsingleobject nicht wait_object_0 zurückgibt, wird nicht geloggt, das gefällt mir gar nicht... |
Re: SOAP-Bombardement
vielen dank für die rege beteiligung
es sind prozesse und ich kriege sie mit meinem semaphore hinreichend gut synchronisiert. wenn das semaphore-handle nicht größer 0 ist (kam noch nicht vor) bzw waitforsingleobjects dem prozess nicht innerhalb der 5s zugang gewährt, weil andere prozesse dies verhindern (kam schon vor), kann er halt bestimmte dinge nicht tun, naja, schicksal bis zur nächsten frage.. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 10:17 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz