James, you make too much sense :) Mind filing a jira for that enhancement? Thanks, Andrew
On Thu, May 4, 2017, 9:56 AM James McMahon <[email protected]> wrote: > 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 >> > >
