Erkennen von gelöschten Nachrichten in ZeroMQ-Warteschlangen

Question

Da es anscheinend nicht möglich ist, die zugrunde liegenden ZeroMQ-Queues/Buffer-Sockets abzufragen/zu inspizieren, um zu sehen, wie stark sie genutzt werden, gibt es eine Möglichkeit, zu erkennen, wann eine Nachricht aufgrund von full abgebrochen wird Puffer in einem Publisher-Socket beim Senden/In Warteschlange?

Wenn die Publisher-Warteschlange beispielsweise voll ist, wird die Nachricht einfach durch die Operation zmq_send gelöscht.

Grundsätzlich möchte ich eine Möglichkeit finden, Situationen zu erkennen, in denen die Warteschlangen gestresst und/oder voll sind, um die Lösung (später) besser auf die Arbeit abzustimmen. Ein alternativer Weg wäre das Hinzufügen einer Sequenznummer zu jeder Nachricht und eine einfache Berechnung im Teilnehmer, aber ich kann niemals sicher sein, dass eine Nachricht aufgrund der vollen Puffer im Herausgeber verloren gegangen ist.

Answer 1

ein Beispiel dafür in der ZeroMQ Guide ist (die Sie sollten lesen und verdauen, wenn Sie 0MQ glücklich verwenden möchten): http://zguide.zeromq.org/page:all#Slow-Subscriber-Detection-Suicidal-Snail-Pattern

Der Mechanismus ist, wie Sie selbst beantwortet, eine Sequenznummer in der hinzufügen Nachricht, und ermöglichen Sie dem Teilnehmer Lücken zu erkennen und geeignete Maßnahmen zu ergreifen. Für die meisten Pubsub-Szenarien können Sie die Standard-HWM, die 1000 ist, auf etwas höher erhöhen; Es hängt von Ihrer durchschnittlichen Nachrichtengröße ab.

Answer 2

Ich weiß, dies ist ein alter Beitrag, aber hier ist, was ich getan habe, wenn vor kurzem das gleiche Problem.

Ich entschied ich ein DEALER/ROUTER zu verwenden und stellen Sie die ZMQ_SNDHWM Option 1. Ebenfalls bereitgestellt ich die Timeout-Parameter für jeden zmq_send(). Die Zeitüberschreitung kann je nach Szenario zwischen 10 und 3 Sekunden liegen (lokaler oder entfernter Sendevorgang).

Wenn die Nachricht nicht innerhalb des Zeitlimits gesendet wird oder der Sendepuffer voll ist, gibt den Wert false zurück. Dadurch konnte ich eine Wiederholungswarteschlange vor zmq einrichten. Ich weiß, es ist keine perfekte Lösung, aber für mich hat es gut geklappt. Was mich jedoch verwirrt, ist die Bedeutung von wahr/falsch, die von der -socket zmq_send() zurückgegeben wird. Ich konnte die Antwort auf diese Frage nicht finden. Ob es darauf hinweist, dass die Nachricht gepuffert wurde oder dass die Nachricht an die ROUTER übermittelt wurde, ist mir entgangen. In meinem Fall habe ich die Ergebnisse trotzdem benötigt.

Nur für den Rekord wurde dies mit netmq getan, aber ich denke, es gilt auch für ZeroMQ.

Ich stimme mit james obwohl. ZeroMQ (und Netmq) sollte zumindest eine Möglichkeit bieten, die Warteschlange zu überprüfen (und die Nachrichten abzurufen) und auch eine Möglichkeit, den verschiedenen Sockets mitzuteilen, dass Nachrichten nicht gelöscht werden sollen. Die beste Option wäre, Nachrichten, die nicht rechtzeitig zu den konfigurierten Optionen geliefert werden, an eine Art Deadletter-Warteschlange zu senden. Die Deadletter-Warteschlange könnte dann separat behandelt werden.