amqp$deliveryMode
from the documentation:
Attributes extracted from the FlowFile are considered candidates for AMQP
properties if their names are prefixed with *amqp$* (e.g.,
amqp$contentType=text/xml). To enrich message with additional AMQP
properties you may use *UpdateAttribute* processor between the source
processor and PublishAMQP processor. The following is the list of available
standard AMQP properties: *("amqp$contentType", "amqp$contentEncoding",
"amqp$headers", "amqp$deliveryMode", "amqp$priority", "amqp$correlationId",
"amqp$replyTo", "amqp$expiration", "amqp$messageId", "amqp$timestamp",
"amqp$type", "amqp$userId", "amqp$appId", "amqp$clusterId")*
I assume folks use this approach, preceding PublishAMQP with an extra
UpdateAttribute.
If anyone does something differently, I'd welcome your feedback.
A question the suggests itself: why aren't these options included as
optional config parms in PublishAMQP itself? Seems odd to require the extra
UpdateAttribute step.
On Thu, May 4, 2017 at 7:21 AM, James McMahon <[email protected]> wrote:
> New to using PublishAMQP and interested in applying best practices. I've
> made a mistake in my initial use, in which messages I posted to RabbitMQ
> were gone from my queues after I restarted the message broker. Goofy
> mistake, but thankfully I am in development prior to production use.
>
> I realize that I am not publishing persistently. I don't see any immediate
> configuration option in the PublishAMQP processor to dictate persistent
> publication to the exchange and bound queues.
>
> What is the best practice folks employ to publish messages that persist?
> Thanks very much in advance for any insights. - Jim
>
