Windows Message Loop Queue Kapazität

[RSE]

Hallo,

ich bin gerade dabei mich etwas in das Thema Windows-Messages, Message-Loop usw. einzulesen. Dabei stellen sich mir momentan 2 Fragen, die sich nicht so recht klären lassen (ich finde dazu einfach nichts).

1. Hat MSMQ etwas mit meiner normalen Delphi Application Message Queue zu tun, aus der in der Application Loop mittels GetMessage bzw. PeekMessage die Messages entnommen und mit TranslateMessage und DispatchMessage verarbeitet werden?
2. Hat die Queue für die Message Loop meiner Application irgendwelche Kapazitätsbeschränkungen, oder könnten da theoretisch Abermillionen von Messages auflaufen?

[himitsu]

2:

Zitat:

10000 by default, but it can be adjusted via the registry.

If queue overflows, PostMessage fails.

Man könnte es also ganz einfach (grob) testen.

- Message Queue leeren
- PostMessages versenden, bis nix mehr geht (und dabei mitzählen)


Aber wenn es damit Probleme gibt, dann läuft in deinem Programm sowieso irgendwas ganz gewaltig schief.

[RSE]

Konkrete Probleme gibt es nicht, es interessiert mich nur einfach. Irgendwo hab ich gelesen, wenn PostMessage nicht erfolgreich ist, muss man es noch einmal probieren. Offengelassen wurde dabei, was in der Zwischenzeit geschehen muss, damit es beim zweiten Versuch überhaupt klappen kann.

Zitat von himitsu:

Zitat:

10000 by default, but it can be adjusted via the registry.

If queue overflows, PostMessage fails.

Man könnte es also ganz einfach (grob) testen.

- Message Queue leeren
- PostMessages versenden, bis nix mehr geht (und dabei mitzählen)

Damit würde man voraussetzen, dass eine Grenze in der Anzahl der Messages besteht. Ich hätte z.B. auch eine Begrenzung des Speicherbedarfes für möglich gehalten. Irgendwo hab ich mal was gelesen, was auf das Mitliefern von Daten hindeutete, könnte aber u.U. um andere "Messages" gegangen sein, da sehe ich noch nicht 100%ig durch (siehe 1.).

[himitsu]

Messages in der Queue sind immer gleich groß, also wäre eine Anzahlbegrenzung gleichbedeutend mit einer Größen-Begrenzung (der Queue).

Was dann in den LParam- und WParam-Parametern referenziert ist, ist der Queue vollkommen egal.

[RSE]

Zitat von himitsu:

Was dann in den LParam- und WParam-Parametern referenziert ist, ist der Queue vollkommen egal.

Logisch, ich bezog mich rein darauf:

Zitat von RSE:

Irgendwo hab ich mal was gelesen, was auf das Mitliefern von Daten hindeutete, könnte aber u.U. um andere "Messages" gegangen sein, da sehe ich noch nicht 100%ig durch (siehe 1.).

Konkret also: Wenn es die Möglichkeit gibt, der Message selbst eine Speicherreservierung im Verantwortungsbereich der Message (also keinen Zeiger auf in der Application reservierten Speicher) mitzugeben (= Daten direkt anzuhängen), dann wäre eine Begrenzung nach MB ungleich einer Begrenzung nach Anzahl. Offenbar trifft das aber nicht zu. Bei dem, was ich da mal gelesen hab, muss es um ein anderes Messaging-System gegangen sein (vielleicht dieses MSMQ).

Zusammenfassung des Beantwortungsstandes bis jetzt:

1. vollkommen offen
2. Eine Begrenzung scheint nach Anzahl Messages zu existieren. Unklar: Wenn PostMessage aufgrund einer vollen Queue fehlschlägt, soll man es noch einmal probieren. Was muss in der Zwischenzeit geschehen, damit es beim zweiten Versuch überhaupt klappen kann? Hilft hier nur ProcessMessage(s)? Das fände ich für meinen Anwendungsfall echt blöd.
   Mein Anwendungsszenario:
   Ich reagiere auf Events einer Telefonanlage. Manchmal hängen mehrere davon in der Queue. Diese müssen in der korrekten Reihenfolge abgearbeitet werden. Muss ich nun in einem Event-Handler eine Messagebox anzeigen, dann würden an dieser Stelle die anderen wartenden Events abgearbeitet (das modale Fenster der Messagebox arbeitet mit ProcessMessages) und der Rest des Event-Handlers würde erst nach den anderen Events abgearbeitet. Deshalb sende ich mir eine Message und zeige die Meldung erst an, wenn ich die Message erhalten habe (also asynchron). Werde ich meine Message an der Stelle nicht los, weil die Queue voll ist, kann ich sie also auch nicht leeren, um die Message loszuwerden.

[sx2008]

Zitat von RSE:

Hat MSMQ etwas mit meiner normalen Delphi Application Message Queue zu tun

Nein, absolut gar nichts.
MSMQ ist eine Technik bei der Funktionsaufrufe in einer Queue zwischengespeichert werden, solange das Ziel gerade nicht erreichbar ist.
Die Funktionsaufrufe gehen dabei über Rechnergrenzen hinweg.

[mjustin]

Zitat von sx2008:

Zitat von RSE:

Hat MSMQ etwas mit meiner normalen Delphi Application Message Queue zu tun

Nein, absolut gar nichts.
MSMQ ist eine Technik bei der Funktionsaufrufe in einer Queue zwischengespeichert werden, solange das Ziel gerade nicht erreichbar ist.
Die Funktionsaufrufe gehen dabei über Rechnergrenzen hinweg.

Funktionsaufrufe würde ich es nicht nennen, eher "Daten" oder "Nachrichten". Diese können natürlich auch Befehle enthalten, die ein Empfänger verarbeiten und optional auch mit einer Nachricht an den Absender beantworten (oder an wiederum andere weiterleiten) soll. Die Daten können auch Dokumente sein.

Praktisch wenn man z.B. Datenbankpolling vermeiden will, man dreht die Sache um und sendet vom Server genau dann eine Nachricht an alle interessierten Clients, wenn es etwas Neues gibt.

Anderer Einsatzbereich: Lastverteilung. Jede Nachricht ist zum Beispiel ein Arbeitsauftrag (Beispiel: eine neue Bestellung). Von allen an der "Bestellungsqueue" angemeldeten Clients erhält genau einer den Auftrag, so werden alle Clients (Server in einem Serverfarm) gleichmäßig ausgelastet.

Stichwort zum Weiterlesen: Enterprise Integration Patterns.

Viele Grüße

[RSE]

Vielen Dank für die Aufklärung bzgl. Frage 1 MSMQ. Ich liebe es, wenn ähnliche aber dennoch verschiedene Technologien so gleich betitelt werden, dass man als "Anfänger" in diesen Technologien oder als Hilfesuchender einfach durcheinanderkommen muss.

Aktueller Beantwortungsstand:

1. Beantwortet
2. Im Kern beantwortet:
   

   Zitat von RSE:

   Eine Begrenzung scheint nach Anzahl Messages zu existieren. Unklar: Wenn PostMessage aufgrund einer vollen Queue fehlschlägt, soll man es noch einmal probieren. Was muss in der Zwischenzeit geschehen, damit es beim zweiten Versuch überhaupt klappen kann? Hilft hier nur ProcessMessage(s)? Das fände ich für meinen Anwendungsfall echt blöd.
   Mein Anwendungsszenario:
   Ich reagiere auf Events einer Telefonanlage. Manchmal hängen mehrere davon in der Queue. Diese müssen in der korrekten Reihenfolge abgearbeitet werden. Muss ich nun in einem Event-Handler eine Messagebox anzeigen, dann würden an dieser Stelle die anderen wartenden Events abgearbeitet (das modale Fenster der Messagebox arbeitet mit ProcessMessages) und der Rest des Event-Handlers würde erst nach den anderen Events abgearbeitet. Deshalb sende ich mir eine Message und zeige die Meldung erst an, wenn ich die Message erhalten habe (also asynchron). Werde ich meine Message an der Stelle nicht los, weil die Queue voll ist, kann ich sie also auch nicht leeren, um die Message loszuwerden.

Ich werde jetzt die Markierung "Offene Frage" entfernen, da der Kern beantwortet ist. Wenn jemend noch weitere Kenntnisse/Ideen zur weiterführenden Frage aus 2. hat, würde ich mich natürlich darüber freuen, wenn diese gepostet werden.