tutorial rabbit how exchange example español downloads java rabbitmq messaging amqp

java - how - RabbitMQ AMQP.BasicProperties.Builder valores



rabbitmq tutorial español (3)

Al momento de escribir:

  1. El último estándar AMQP es AMQP 1.0 OASIS Standard .
  2. La última versión de RabbitMQ es 3.1.5 (servidor y cliente), que afirma ser compatible con AMQP 0.9.1 (pdf y esquemas XML comprimidos).
  3. RabbitMQ proporciona su propia descripción del protocolo como esquema XML que incluye extensiones (es decir, no estándar), más un esquema XML sin extensiones (que es idéntico al esquema vinculado a través de (2)) y documento pdf .

En esta respuesta:

  • Los enlaces en (3) son la fuente principal de detalle.
  • (2) pdf doc se utiliza como detalle secundario si (3) es inadecuado
  • El código fuente (cliente java, servidor erlang) se utiliza como detalle terciario si (2) es inadecuado.
  • (1) generalmente no se usa: el protocolo y el esquema han evolucionado (bastante) significativamente para / por OASIS y deberían aplicarse a las versiones futuras de RabbitMQ, pero no se aplican ahora. Las dos excepciones en las que se usó (1) fueron las descripciones textuales de contentType y contentEncoding , lo cual es seguro, ya que estos son campos estándar con buenas descripciones en AMQP 1.0.

El siguiente texto es parafraseado de estas fuentes por mí para hacer un poco más conciso o claro.

  • tipo de contenido ( tipo XML de AMQP = "shortstr"; tipo de java = "Cadena"): Opcional. El tipo RFC-2046 MIME para la sección de datos de aplicación del mensaje (cuerpo). Puede contener un parámetro de conjunto de caracteres que define la codificación de caracteres utilizada: por ejemplo, ''text / plain; conjunto de caracteres = "utf-8" ''. Cuando se desconoce el tipo de contenido, el tipo de contenido NO DEBE establecerse, lo que permite al destinatario determinar el tipo real. Cuando se sabe que la sección son datos binarios verdaderamente opacos, el tipo de contenido DEBE establecerse en application / octet-stream.
  • codificación de contenido (AMQP XML type = "shortstr"; java type = "String"): Opcional. Cuando está presente, describe codificaciones de contenido adicionales aplicadas a los datos de la aplicación y, por lo tanto, qué mecanismos de decodificación deben aplicarse para obtener el tipo de medio al que hace referencia el campo de encabezado de tipo de contenido. Se utiliza principalmente para permitir que un documento se comprima sin perder la identidad de su tipo de contenido subyacente. Un modificador al tipo de contenido, interpretado según la sección 3.5 de RFC 2616. Las codificaciones de contenido válidas se registran en la IANA. Las implementaciones NO DEBEN utilizar la codificación de compresión, excepto para seguir siendo compatibles con los mensajes enviados originalmente con otros protocolos, por ejemplo, HTTP o SMTP. Las implementaciones NO DEBEN especificar múltiples valores de codificación de contenido, excepto para ser compatibles con los mensajes enviados originalmente con otros protocolos, por ejemplo, HTTP o SMTP.
  • encabezados (AMQP XML type = "table"; java type = "Map"): Opcional. Una lista especificada por la aplicación de los parámetros del encabezado y sus valores. Estos pueden configurarse para uso exclusivo de la aplicación. Además, es posible crear colas con "Tipo de intercambio de encabezado": cuando se crea la cola, se le asigna una serie de nombres de propiedades de encabezado que coinciden, cada uno con valores opcionales que deben coincidir, de modo que el enrutamiento a esta cola se realice a través del encabezado -pareo.
  • deliveryMode (RabbitMQ XML type = "octet"; java type = "Integer"): 1 (no persistente) o 2 (persistente). Solo funciona para colas que implementan persistencia. Un mensaje persistente se guarda de forma segura en el disco y se garantiza que se entregará incluso si hay un fallo grave de la red, un fallo del servidor, un desbordamiento, etc.
  • prioridad (tipo XML de AMQP = "octeto"; tipo de java = "entero"): La prioridad relativa del mensaje ( 0 a 9 ). Un mensaje de alta prioridad es [PUEDE SER ?? - GB] enviados antes de los mensajes de prioridad más baja que esperan en la misma cola de mensajes. Cuando los mensajes se deben descartar para mantener un nivel de calidad de servicio específico, el servidor primero descartará los mensajes de baja prioridad. Solo funciona para colas que implementan prioridades.
  • correlation-id (tipo de XML AMQP = "octeto"; tipo de java = "Cadena"): Opcional. Para uso de la aplicación, no hay comportamiento formal (RabbitMQ). Una identificación específica del cliente que se puede utilizar para marcar o identificar mensajes entre clientes.
  • replyTo (AMQP XML type = "shortstr"; java type = "String"): Opcional. Para el uso de la aplicación, no hay un comportamiento formal (RabbitMQ) pero puede contener el nombre de una cola de respuesta privada, cuando se usa en los mensajes de solicitud. La dirección del nodo al que enviar las respuestas.
  • caducidad (AMQP XML type = "shortstr"; java type = "String"): Opcional. El esquema RabbitMQ AMQP 0.9.1 de (3) indica "Para uso de implementación, sin comportamiento formal". El pdf del esquema AMQP 0.9.1 de (2) indica un tiempo absoluto cuando este mensaje se considera caducado. Sin embargo, estas dos descripciones deben ignorarse porque este enlace TTL y el código cliente / servidor indican que lo siguiente es verdadero. Desde el cliente, la caducidad solo se puede completar a través de la inicialización personalizada de aplicaciones de BasicProperties. En el servidor, esto se usa para determinar el TTL desde el punto en que se recibe el mensaje en el servidor, antes de poner en cola. El servidor selecciona TTL como el mínimo de (1) mensaje TTL ( vencimiento de BasicProperties del cliente como un tiempo relativo en milisegundos ) y (2) TTL de cola ( x-message-ttl configurado en milisegundos). Formato: cadena que representa el número entero de milisegundos; Tiempo de expiración del mensaje recibido en el servidor.
  • message-id (AMQP XML type = "shortstr"; java type = "String"): Opcional. Para uso de la aplicación, no hay comportamiento formal (RabbitMQ). Si se establece, el productor del mensaje debe establecerlo en un valor único global. En el futuro (AMQP 1.0), un agente PUEDE descartar un mensaje como un duplicado si el valor del mensaje-id coincide con el de un mensaje recibido previamente enviado al mismo nodo.
  • timestamp (AMQP XML type = "timestamp"; java type = "java.util.Date"): Opcional. Para uso de la aplicación, no hay comportamiento formal (RabbitMQ). Un tiempo absoluto cuando este mensaje fue creado.
  • type (AMQP XML type = "shortstr"; java type = "String"): Opcional. Para uso de la aplicación, no hay comportamiento formal (RabbitMQ). [Describe que el mensaje pertenece o pertenece a un "tipo" o "formulario" o "transacción comercial" específico de la aplicación - GB]
  • userId (AMQP XML type = "shortstr"; java type = "String"): Opcional. El esquema XML indica "Para uso de la aplicación, sin comportamiento formal (RabbitMQ)", pero creo que esto ha cambiado en la última versión (sigue leyendo). Si se establece, el cliente establece este valor como identidad del usuario responsable de producir el mensaje. Desde RabbitMQ : si esta propiedad está establecida por un editor, su valor debe ser igual al nombre del usuario utilizado para abrir la conexión (es decir, la validación se realiza para garantizar que sea el usuario conectado / autenticado). Si la propiedad de identificación de usuario no está establecida, la identidad del editor permanece privada.
  • appId (RabbitMQ XML type = "shortstr"; java type = "String"): Opcional. Para uso de la aplicación, no hay comportamiento formal (RabbitMQ). La creación de la aplicación id. Puede ser poblada por productores y leída por consumidores. (Mirando el código del servidor R-MQ, el servidor no lo utiliza en absoluto, aunque el complemento "webmachine-wrapper" proporciona un script y las plantillas correspondientes para crear un webmachine, donde un administrador puede proporcionar un ID de aplicación al script).
  • Id. de cluster (RabbitMQ XML type = "N / A"; java type = "String"): Desaprobado en AMQP 0.9.1, es decir, no se utiliza. En versiones anteriores, era el identificador de enrutamiento dentro del clúster, para uso de las aplicaciones de clúster, que no debería ser utilizado por las aplicaciones cliente (es decir, no se completó). Sin embargo, esto ha quedado obsoleto y eliminado del esquema actual y no es utilizado por el código del servidor R-MQ.

Como puede ver arriba, la gran mayoría de estas propiedades no tienen valores enumerados / restringidos / recomendados porque son "solo para uso de la aplicación" y no son utilizadas por RabbitMQ. Así que tienes un trabajo fácil. Usted es libre de escribir / leer valores que son útiles para su aplicación, siempre y cuando coincidan con el tipo de datos y la compilación :). ContentType y contentEncoding son según el uso estándar de HTTP. DeliveryMode y la priority son números restringidos.

Nota: Constantes útiles, pero simples para AMQP.BasicProperties están disponibles en la clase MessageProperties .

Saludos :)

ACTUALIZACIÓN PARA CORREOS:

Con muchas gracias a Renat (ver comentarios), he mirado el código del servidor erlang en rabbit_amqqueue_process.erl y la documentación en RabbitMQ TTL Extensions to AMQP . Se puede especificar la caducidad del mensaje (tiempo de vida)

  • por cola a través de:

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

  • o por mensaje a través de:

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

Aquí, el ttl / expiration está en milisegundos, entonces 60 segundos en cada caso. Tener actualizada la definición de vencimiento para reflejar esto.

En el cliente Java RabbitMQ / AMQP, puede crear un AMQP.BasicProperties.Builder , y usarlo para build() una instancia de AMQP.BasicProperties . Esta instancia de propiedades construidas se puede usar para todo tipo de cosas importantes. Hay muchos métodos de estilo "constructor" disponibles en esta clase de constructor:

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

Estoy buscando qué campos ayudan a "acumularse" estos métodos de builer, y lo más importante, qué valores válidos existen para cada campo . Por ejemplo, ¿qué es un clusterId y cuáles son sus valores válidos? ¿Qué es el type y cuáles son sus valores válidos? Etc.

He pasado toda la mañana recorriendo:

En todos estos documentos, no puedo encontrar definiciones claras (además de una vaga explicación de qué priority , contentEncoding y deliveryMode ) de qué es cada uno de estos campos y cuáles son sus valores válidos. ¿Alguien sabe? Más importante aún, ¿alguien sabe dónde están documentados? ¡Gracias por adelantado!

La especificación AMQP define un modelo genérico y extensible para las propiedades.

Las propiedades de AMQP son algo similares en concepto a los encabezados HTTP, ya que representan metadatos sobre los mensajes en cuestión. Al igual que en HTTP, se enmarcan por separado a la carga útil del mensaje. Pero son básicamente un mapa clave / valor.

Algunos corredores como RabbitMQ interpretarán ciertas propiedades del mensaje, como la expiration para agregar un valor adicional específico del proveedor (en ese caso, imponer un TTL ).

Pero al final, las propiedades de AMQP son solo una gran cantidad de pares clave / valor que se envían de forma segura junto con cada mensaje, si así lo desea. La documentación de su agente de AMQP le dirá cuáles interpretan especialmente y cómo enviar los suyos.

Dicho todo esto, si está haciendo esta pregunta en primer lugar, entonces probablemente no deba preocuparse por ellos en absoluto. Podrá enviar mensajes con éxito sin tener que preocuparse por configurar las propiedades de los mensajes.

Usualmente utilizo un enfoque muy simple para memorizar algo. Proporcionaré todos los detalles a continuación, pero aquí hay una imagen simple del campo y los valores de BasicProperties. También he intentado resaltar correctamente la cola / servidor y el contexto de la aplicación.

Si quieres que lo mejore un poco, solo deja un pequeño comentario. Lo que realmente quiero es proporcionar una clave visual y simplificar la comprensión.

Descripción de alto nivel ( fuente 1 , fuente 2 ):

Tenga en cuenta que Clust ID ha quedado en desuso, por lo que lo excluiré.

  • ID de aplicación : identificador de la aplicación que produjo el mensaje.
    • Contexto: uso de la aplicación
    • Valor: puede ser cualquier cadena.
  • Codificación de contenido - Codificación de contenido de mensaje
    • Contexto: uso de la aplicación
    • Valor: codificación de contenido MIME (por ejemplo, gzip)
  • Tipo de contenido - Tipo de contenido del mensaje
    • Contexto: uso de la aplicación
    • Valor: tipo de contenido MIME (por ejemplo, application / json)
  • ID de correlación : mensaje correlacionado con este, por ejemplo, a qué solicitud responde este mensaje. Se recomienda a las aplicaciones que utilicen este atributo en lugar de poner esta información en la carga útil del mensaje.
    • Contexto: uso de la aplicación
    • Valor: cualquier valor
  • Modo de entrega : ¿debe persistir el mensaje en el disco?
    • Contexto: uso de implementación de la cola
    • Valor: no persistente (1) o persistente (2)
  • Vencimiento : tiempo de caducidad después del cual se eliminará el mensaje. El valor del campo de caducidad describe el período TTL en milisegundos. Por favor, vea los detalles a continuación.
    • Contexto: uso de implementación de la cola
  • Encabezados : encabezados de mensajes específicos de aplicaciones arbitrarias.
    • Contexto: uso de la aplicación
  • ID de mensaje: identificador de mensaje como una cadena. Si las aplicaciones necesitan identificar mensajes, se recomienda que utilicen este atributo en lugar de ponerlo en la carga útil del mensaje.
    • Contexto: uso de la aplicación
    • Valor: cualquier valor
  • Prioridad - Prioridad del mensaje.
    • Contexto: uso de implementación de la cola
    • Valores: 0 a 9
  • ReplyTo : nombre de la cola a la que otras aplicaciones deben enviar la respuesta. Normalmente se usa para nombrar una cola de respuestas (o cualquier otro identificador que ayude a una aplicación del consumidor a dirigir su respuesta). Se recomienda a las aplicaciones que utilicen este atributo en lugar de poner esta información en la carga útil del mensaje.
    • Contexto: uso de la aplicación
    • Valor: cualquier valor
  • Marca de tiempo: marca de tiempo del momento en que se envió el mensaje.
    • Contexto: uso de la aplicación
    • Valor: Segundos desde la Época.
  • Tipo : tipo de mensaje, por ejemplo, qué tipo de evento o comando representa este mensaje. Recomendado para ser utilizado por las aplicaciones en lugar de incluir esta información en la carga útil del mensaje.
    • Contexto: uso de la aplicación
    • Valor: puede ser cualquier cadena.
  • ID de usuario - ID de usuario opcional. Verificado por RabbitMQ contra el nombre de usuario de la conexión real.
    • Contexto: uso de implementación de la cola
    • Valor: Debe ser usuario autenticado.

Por cierto, finalmente logré revisar el último código de servidor ( rabbitmq-server-3.1.5 ), hay un ejemplo en 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">>}]

Es bueno saber que alguien quiere saber todos los detalles. Porque es mucho mejor usar atributos de mensaje conocidos cuando sea posible en lugar de colocar información en el cuerpo del mensaje. Por cierto, las propiedades básicas de los mensajes están lejos de ser claras y útiles. Yo diría que es mejor usar uno personalizado.

Buen ejemplo ( source )

Actualización - Campo de expiración

Nota importante: la caducidad pertenece al contexto de la cola. Así que el mensaje podría ser eliminado por los servidores.

README dice lo siguiente:

expiration es un shortstr; Ya que RabbitMQ espera que esto sea una cadena codificada, traducimos un ttl a la representación de cadena de su valor entero.

Fuentes: