AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Thema durchsuchen
Ansicht
Themen-Optionen

SOAP-Bombardement

Ein Thema von hyype · begonnen am 2. Mär 2009 · letzter Beitrag vom 17. Mär 2009
Antwort Antwort
hyype

Registriert seit: 5. Nov 2008
97 Beiträge
 
Delphi XE2 Professional
 
#1

SOAP-Bombardement

  Alt 2. Mär 2009, 17:34
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
  Mit Zitat antworten Zitat
hyype

Registriert seit: 5. Nov 2008
97 Beiträge
 
Delphi XE2 Professional
 
#2

Re: SOAP-Bombardement

  Alt 4. Mär 2009, 08:49
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:
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;
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!
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...
  Mit Zitat antworten Zitat
hyype

Registriert seit: 5. Nov 2008
97 Beiträge
 
Delphi XE2 Professional
 
#3

Re: SOAP-Bombardement

  Alt 17. Mär 2009, 14:20
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..
  Mit Zitat antworten Zitat
Antwort Antwort


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 18:14 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz