RabbitMQ AMQP.BasicProperties.Builder-Werte

In der RabbitMQ/AMQP-Java-client, erstellen Sie eine AMQP.BasicProperties.Builderund es verwenden, um build() eine Instanz von AMQP.BasicProperties. Diese integrierten Eigenschaften-Instanz kann dann verwendet werden, um alle Arten wichtiger Dinge. Es gibt viele "builder"-Stil Methoden zur Verfügung, die auf diese builder-Klasse:

BasicProperties.Builder propsBuilder = new BasicProperties.Builder();
propsBuilder
    .appId(???)
    .clusterId(???)
    .contentEncoding(???)
    .contentType(???)
    .correlationId(???)
    .deliveryMode(2)
    .expiration(???)
    .headers(???)
    .messageId(???)
    .priority(???)
    .replyTo(???)
    .timestamp(???)
    .type(???)
    .userId(???);

Ich bin auf der Suche, für welche Felder diese builer Methoden helfen "build-up", und vor allem, was gültige Werte existieren für jedes Feld. Zum Beispiel, was ist ein clusterIdund was sind die gültigen Werte? Was ist typeund was sind die gültigen Werte? Etc.

Habe ich verbrachte den ganzen morgen scheuern:

In all diesen docs, ich kann nicht finden, klare Definitionen (neben einigen vage Erklärung, was prioritycontentEncoding und deliveryMode sind), was diese Felder sind und was Ihre Werte sind gültig. Hat jemand das wissen? Noch wichtiger ist, weiß jemand, wo diese sind auch dokumentiert? Vielen Dank im Voraus!

InformationsquelleAutor der Frage | 2013-08-23

  1. 73

    Normalerweise verwende ich eine sehr einfache Methode etwas auswendig zu lernen. Ich werde alle details unter, aber hier ist ein einfaches Bild, BasicProperties Feld und Werte. Ich habe auch versucht, richtig zu markieren, queue/server-und Anwendungs-Kontext.

    RabbitMQ AMQP.BasicProperties.Builder-Werte

    Wenn Sie mich wollen, Sie zu verbessern ein bisschen - werfen Sie einfach einen kleinen Kommentar. Was ich wirklich will, ist einigen visual key und vereinfacht das Verständnis.

    High-level-Beschreibung (Quelle 1Quelle 2):

    Bitte beachten Sie Clust-ID ist veraltet, also werde ich es ausschließen.

    • Anwendungs-ID - Id der Anwendung, erzeugt die Nachricht.
      • Kontext: Anwendung verwenden
      • Wert: Kann ein beliebiger string sein.
    • Content-Encoding - Message-Codierung von Inhalten
      • Kontext: Anwendung verwenden
      • Wert: MIME-Codierung von Inhalten (z.B. gzip)
    • Content-Type - Message-content-type
      • Kontext: Anwendung verwenden
      • Wert: MIME-content-type (z.B. application/json)
    • Korrelations-ID - Nachricht korreliert werden, z.B. welche Anfrage diese Nachricht ist eine Antwort auf. Anwendungen werden ermutigt, verwenden Sie dieses Attribut, anstatt diese Informationen in der message-payload.
      • Kontext: Anwendung verwenden
      • Wert: ein beliebiger Wert
    • Lieferung-Modus - Sollte die Botschaft sein, die auf dem Datenträger beibehalten?
      • Kontext: queue-Implementierung verwenden
      • - Wert: non-persistent (1) oder persistent (2)
    • Ablauf - Ablauf der Zeit, nach der die Nachricht gelöscht werden. Der Wert des Ablauf Feld beschreibt die TTL-Zeit in Millisekunden. Bitte sehen Sie details unten.
      • Kontext: queue-Implementierung verwenden
    • Header - Beliebige Anwendung-spezifische message-Header.
      • Kontext: Anwendung verwenden
    • Message-ID - Message-identifier als string zurück. Wenn die Anwendungen benötigen, um Nachrichten zu erkennen, wird empfohlen, dass Sie verwenden dieses Attribut, anstatt Sie in der message-payload.
      • Kontext: Anwendung verwenden
      • Wert: ein beliebiger Wert
    • Priorität - Nachricht Priorität.
      • Kontext: queue-Implementierung verwenden
      • Werte: 0 bis 9
    • "ReplyTo" - Queue-Namen an andere apps senden der Antwort. Häufig verwendet, um Namen eine Antwort-Warteschlange (oder eine beliebige andere id, die hilft, eine consumer-Anwendung, um direkte Antwort). Anwendungen werden ermutigt, verwenden Sie dieses Attribut, anstatt diese Informationen in der message-payload.
      • Kontext: Anwendung verwenden
      • Wert: ein beliebiger Wert
    • Zeit-Stempel - Zeitstempel von dem moment an, wenn die Nachricht gesendet wurde.
      • Kontext: Anwendung verwenden
      • Wert: Sekunden seit Beginn der Epoche zurück.
    • Typ - Message-Typ, z.B. welche Art von Ereignis oder Befehl diese Nachricht repräsentiert. Empfohlen von Anwendungen verwendet zu werden, statt diese Informationen in der message-payload.
      • Kontext: Anwendung verwenden
      • Wert: Kann ein beliebiger string sein.
    • Benutzer-ID - Optionale Benutzer-ID. Verifiziert durch RabbitMQ gegen die eigentliche Verbindung Benutzername.
      • Kontext: queue-Implementierung verwenden
      • Wert: Sollte authentifizierte Benutzer.

    BTW, ich habe es endlich geschafft, ein review neueste Server-code (rabbitmq-server-3.1.5), es gibt ein Beispiel in rabbit_stomp_test_util.erl:

                    content_type     = <<"text/plain">>,
                content_encoding = <<"UTF-8">>,
                delivery_mode    = 2,
                priority         = 1,
                correlation_id   = <<"123">>,
                reply_to         = <<"something">>,
                expiration       = <<"my-expiration">>,
                message_id       = <<"M123">>,
                timestamp        = 123456,
                type             = <<"freshly-squeezed">>,
                user_id          = <<"joe">>,
                app_id           = <<"joe's app">>,
                headers          = [{<<"str">>, longstr, <<"foo">>},
                                    {<<"int">>, longstr, <<"123">>}]

    Gut zu wissen, jemand will alle details wissen. Da ist es viel besser, die die bekannten message-Attribute wenn möglich, statt Informationen im Textkörper der Nachricht. BTW, basic-message-Eigenschaften sind bei weitem nicht klar und nützlich. Ich würde sagen, es ist besser, verwenden Sie eine benutzerdefinierte.

    RabbitMQ AMQP.BasicProperties.Builder-Werte

    Gutes Beispiel (Quelle)

    RabbitMQ AMQP.BasicProperties.Builder-Werte

    Update - Ablauf Feld

    Wichtiger Hinweis: Ablauf gehört zu Warteschlange Kontext. So Nachricht kann gelöscht werden vom Server.

    RabbitMQ AMQP.BasicProperties.Builder-Werte

    README sagt Folgendes:

    expiration ist ein shortstr; seit RabbitMQ wird erwarten, dass diese
    eine codierte Zeichenfolge, die wir übersetzen, ein ttl um die string-Darstellung
    von seinen integer-Wert.

    Quellen:

    InformationsquelleAutor der Antwort

  2. 9

    Zum Zeitpunkt des Schreibens:

    1. Die aktuellen AMQP-standard ist AMQP 1.0 IST OASIS-Standard.
    2. Die neueste version von RabbitMQ ist 3.1.5 (server und client), welche Ansprüche auf Unterstützung AMQP 0.9.1 (pdf und XML-schemas Zip).
    3. RabbitMQ bietet es eigene Beschreibung des Protokolls als XML-schema einschließlich der Erweiterungen (d.h. nicht-standard), plus XML-schema-ohne extensions (die identisch ist mit dem schema verbunden über (2)) und pdf doc.

    In dieser Antwort:

    • links in (3) sind die primäre Quelle von detail
    • (2) pdf-Dokument wird als sekundäres detail, wenn (3) unzureichend ist
    • Den source-code (java-client, erlang-server) dient als tertiäre detail, wenn (2) ist unzureichend.
    • (1) ist in der Regel nicht verwendet werden, - Protokoll und-schema wurden (ziemlich) deutlich entwickelt für/von OASIS und sollte für zukünftige Versionen von RabbitMQ, aber gelten nicht jetzt. Die zwei Ausnahmen, bei denen (1) verwendet wurde, wurde für textuelle Beschreibungen contentType und contentEncoding - das ist sicher, denn diese sind standard-Felder, die mit guten Beschreibungen im AMQP 1.0.

    Den folgenden text paraphrasiert aus diesen Quellen, die mich zu ein wenig mehr präzise oder klar.

    • content-type (AMQP XML type="shortstr"; java-type="String"): Optional. Die RFC-2046 MIME-Typ für die Nachricht-Anwendung-Daten-Bereich (Körper). Enthalten kann, einen charset-parameter definieren die verwendete Zeichenkodierung: z.B. 'text/plain; charset="utf-8"'. Wo der Inhalt Typ unbekannt ist der content-type NICHT gesetzt werden, so dass der Empfänger bestimmen die tatsächliche type. Der Abschnitt bekannt ist, um wirklich deckend binären Daten, den content-Typ SOLLTE auf application/octet-stream.
    • content-encoding (AMQP XML type="shortstr"; java-type="String"): Optional. Wenn vorhanden, beschrieben, zusätzliche Inhalte, Codierungen für die Anwendung verwendet ist-Daten, und damit, was die Decodierung Mechanismen angewendet werden müssen, um die media-type wird durch den content-type header-Feld. In Erster Linie verwendet, um ein Dokument komprimiert werden, ohne dabei die Identität der zugrunde liegenden content-Typ. Ein Modifikator auf den content-Typ, interpretiert, wie in Abschnitt 3.5 der RFC 2616. Gültigen content-encodings werden bei der IANA registriert. Implementierungen SOLLTEN NICHT die Kodierung komprimieren, mit Ausnahme der an kompatibel bleiben mit Nachrichten ursprünglich gesendet hat, mit anderen Protokollen, z.B. HTTP oder SMTP. Implementierungen SOLLTEN NICHT angeben, mehrere content-encoding-Werte außer als kompatibel mit den Nachrichten ursprünglich gesendet hat, mit anderen Protokollen, z.B. HTTP oder SMTP.
    • Header (AMQP XML-Typ="Tabelle"; java-type="Map"): Optional. Eine Anwendung spezifizierte Liste von header-Parametern und deren Werte. Diese können sein setup für die Anwendung-verwenden Sie nur. Darüber hinaus ist es möglich, erstellen von Warteschlangen mit "Header" Exchange Type" - wenn die Warteschlange erstellt wird, ist es gegeben, eine Reihe von header-property-Namen übereinstimmen, die jeweils mit optionalen Werte aufeinander abgestimmt werden, so dass das routing zu dieser Warteschlange erfolgt über die header-matching.
    • deliveryMode (RabbitMQ-Typ XML="Oktett"; java-type="Integer"): 1 (non-persistent) oder 2 (persistent). Funktioniert nur für Warteschlangen, die Implementierung der Persistenz. Eine persistente Nachricht sicher gehalten wird, auf der Festplatte und garantiert geliefert werden
      auch wenn es ein schwerwiegender Netzwerkfehler, server-crash, überlauf etc.
    • Priorität (AMQP XML type="Oktett"; java-type="Integer"): Die relative Priorität der Nachrichten (0 bis 9). Eine Nachricht mit hoher Priorität ist, [KANN das SEIN??? - GB] gesendet vor niedrigeren Priorität Nachrichten, die in die gleiche message queue. Wenn Nachrichten verworfen werden muss, um eine bestimmte service-Qualität der server zuerst verwerfen Nachrichten mit niedriger Priorität. Funktioniert nur für Warteschlangen mit Prioritäten umzusetzen.
    • Korrelation-id (AMQP XML type="Oktett"; java-type="String"): Optional. Für die Anwendung verwenden, die keine formale (RabbitMQ) Verhalten. Eine client-spezifische id, die verwendet werden können, zu Kennzeichnen oder identifizieren, die Nachrichten zwischen clients.
    • "replyTo" (AMQP XML type="shortstr"; java-type="String"): Optional. Für die Anwendung verwenden, die keine formale (RabbitMQ) Verhalten, sondern möglicherweise der name einer privaten Antwort-queue, wenn im request-Nachrichten. Die Adresse des Knotens zum senden von Antworten an.
    • Ablauf (AMQP XML type="shortstr"; java-type="String"): Optional. RabbitMQ AMQP 0.9.1-schema von (3) besagt, "Für die Umsetzung verwenden, die keine formale Verhalten". Der AMQP 0.9.1-schema pdf-Datei aus (2) Staaten, die eine absolute Zeit, wenn Sie diese Nachricht als abgelaufen. Allerdings diese beiden Bezeichnungen müssen ignoriert werden weil diese TTL-link und die client - /server-code zeigen die folgenden Bedingungen wahr ist. Von den Kunden, Ablaufdatum wird nur ausgefüllt werden, die über benutzerdefinierte Anwendung die Initialisierung von BasicProperties. Auf dem server, diese wird verwendet, um zu bestimmen, TTL von dem Punkt, dass die Nachricht am server empfangen wird, bevor queuing. Der server wählt TTL als das minimum von (1) - Nachricht TTL (client BasicProperties Ablauf als relative Zeit in Millisekunden) und (2) Warteschlange TTL (konfiguriert x-message-ttl in Millisekunden). Format: string, Ganzzahl, die die Anzahl von Millisekunden; die Zeit der Ablauf von der Meldung empfangen wird auf dem server.
    • message-id (AMQP XML type="shortstr"; java-type="String"): Optional. Für die Anwendung verwenden, die keine formale (RabbitMQ) Verhalten. Wenn gesetzt, wird die Meldung Produzent sollte es zu einer weltweit einzigartigen Wert. In Zukunft (AMQP 1.0), der broker verwerfen einer Nachricht als Duplikat, wenn der Wert der Nachrichten-id übereinstimmt, die einer zuvor empfangenen Nachricht gesendet, um den gleichen Knoten.
    • timestamp (AMQP XML type="timestamp"; java-type="java.util.Datum"): Optional. Für die Anwendung verwenden, die keine formale (RabbitMQ) Verhalten. Eine absolute Zeit, wenn diese Nachricht erstellt wurde.
    • Typ (AMQP XML type="shortstr"; java-type="String"): Optional. Für die Anwendung verwenden, die keine formale (RabbitMQ) Verhalten. [Beschreibt die Nachricht als " der /die Zugehörigkeit zu einer Anwendungs-spezifischen "Art" oder "form" oder "Geschäft" - GB]
    • userId (AMQP XML type="shortstr"; java-type="String"): Optional. XML-Schema-Staaten "Für die Anwendung verwenden, die keine formale (RabbitMQ) Verhalten" - aber ich glaube, das hat sich verändert in der neuesten Version (Lesen Sie weiter). Wenn gesetzt, wird der client setzt diesen Wert als die Identität der Nutzer verantwortlich für die Herstellung der Nachricht. Von RabbitMQ: Wenn diese Eigenschaft gesetzt ist, von einem Herausgeber, der Wert muss gleich dem Namen des Benutzers verwendet, um die Verbindung zu öffnen (D. H. eine überprüfung erfolgt, um sicherzustellen, dass die angeschlossenen/authentifizierte Benutzer). Wenn die Benutzer-id-Eigenschaft nicht gesetzt ist, wird der Herausgeber die Identität bleibt im privaten.
    • appId (RabbitMQ-Typ XML="shortstr"; java-type="String"): Optional. Für die Anwendung verwenden, die keine formale (RabbitMQ) Verhalten. Das erstellen id der Anwendung. Gefüllt werden können die Produzenten und Lesen durch die Verbraucher. (R-MQ-server-code, das ist gar nicht vom server, obwohl die "webmachine-wrapper" plugin stellt ein Skript und passende Vorlagen zum erstellen einer webmachine - wo ein admin kann eine Anwendungs-id für das Skript.)
    • cluster-Id (RabbitMQ-Typ XML="N/A"; java-type="String"): Deprecated in AMQP 0.9.1, d.h. nicht verwendet. In früheren Versionen war der intra-cluster routing-Kennung für die Verwendung von cluster-Anwendungen, die nicht verwendet werden dürfen, die von client-Anwendungen (also nicht ausgefüllt). Dies wurde jedoch abgelehnt und entfernt von der aktuellen Schemas und nicht von R-MQ-server-code.

    Wie Sie oben sehen können, die überwiegende Mehrheit der diese Eigenschaften nicht aufgelistet habe /eingeschränkt /empfohlenen Werte, weil Sie "Anwendung" und nicht von RabbitMQ. So haben Sie einen einfachen job. Du bist frei zu schreiben/Lesen, Werte, die nützlich für Ihre Anwendung - so lange, wie Sie passen, Datentyp und kompilieren :). ContentType und contentEncoding sind, wie pro standard-HTTP verwenden. DeliveryMode und priority gezwungen sind, zahlen.

    Hinweis: Nützlich, aber einfache Konstanten für AMQP.BasicProperties sind in der Klasse MessageProperties.

    Prost 🙂

    UPDATE ZU POSTEN:

    Vielen Dank an Renat (siehe Kommentare), habe mir bei erlang-server-code in rabbit_amqqueue_process.erl und-Dokumentation RabbitMQ TTL-Erweiterungen AMQP. Message-Ablauf ("time-to-live) festgelegt werden kann

    • pro Warteschlange über:

      Map<String, Object> args = new HashMap<String, Object>();
args.put("x-message-ttl", 60000);
channel.queueDeclare("myqueue", false, false, false, args);

    • oder per Nachricht über:

      byte[] messageBodyBytes = "Hello, world!".getBytes();
AMQP.BasicProperties properties = new AMQP.BasicProperties();
properties.setExpiration("60000");
channel.basicPublish("my-exchange", "routing-key", properties, messageBodyBytes);

    Hier die Gültigkeitsdauer/Ablaufdatum ist in millisecs, also 60 Sek. in jedem Fall.
    Aktualisiert haben oben erwähnte definition von Ablauf, um dies zu reflektieren.

    InformationsquelleAutor der Antwort Glen Best

  3. 0

    Den AMQP Spezifikation definiert ein generisches, erweiterbares Modell für Eigenschaften.

    AMQP-Eigenschaften sind sehr ähnlich im Konzept, um HTTP-Header, in das Sie repräsentieren Metadaten über die Nachrichten in Frage. Nur, wie in HTTP, Sie sind umrahmt separat auf die message-payload. Aber im Grunde sind Sie ein Schlüssel/Wert-Karte.

    Einige Broker wie RabbitMQ interpretiert werden bestimmte Eigenschaften Nachricht wie expiration um zusätzliche Hersteller-spezifischen Wert (in diesem Fall die Durchsetzung eines TTL).

    Aber am Ende, AMQP-Eigenschaften sind nur ein großer Haufen von Schlüssel/Wert-Paare, die sich sicher geschickt, zusammen mit jeder Nachricht, die Sie wählen sollten, zu tun. Ihre AMQP broker-Dokumentation wird Ihnen sagen, welche diejenigen, die Sie interpretieren, und speziell, wie Sie zum senden Ihrer eigenen.

    Alle, die being said, wenn Sie Fragen, diese Frage in den ersten Platz, dann haben Sie wahrscheinlich nicht brauchen, um über Sie überhaupt. Werden Sie erfolgreich in der Lage, Nachrichten zu senden, ohne sich sorgen über irgendwelche message-Eigenschaften an alle.

    InformationsquelleAutor der Antwort Brian Kelly

Schreibe einen Kommentar