On 20-02-14 16:55, Paolo Lucente wrote:
> Thanks for your patches. Most of the minor issues were already fixed in
> the CVS code; i've fixed the couple remaining. The memory leak is not a
> "real" one: some structures are not free'd up in amqp_cache_purge() but
> such function is called in a writer, ephemeral processes spawned each
> amqp_refresh_time intervals: once these processes are terminated the OS
> does take back all resources anyway.
> About the new feature you implemented: i'm reviewing the code (you did
> a very good job) and i'm happy to commit it to the CVS code. Just one
> question: what is your use-case for durable message support? Something
> like be able to recover un-processed JSON objects in case of reboot/
> restart of RabbitMQ?

We currently have a setup that uses sfacct to read sFlow data, and uses
rabbitmq with logstash to finally insert it into elasticsearch after
some filtering by logstash.

We use sFlow/sfacct to monitor and store data usage for all IPs
traveling through our network. This data is then used to bill our
customers. In this case, any loss of traffic information is unwanted,
because that would either be unfair to our customers, or cut our revenue.

By default, the sfacct / rabbitmq / logstash setup will drop any
messages and clear all queues during reboot/restart. Logstash can create
a rabbitmq queue as durable, but sfacct could not mark the messages
durable as well. Both settings are needed to keep messages from being
dropped in case logstash can't consume them, or any of the services are

Kind regards,

Nick Douma

Attachment: signature.asc
Description: OpenPGP digital signature

pmacct-discussion mailing list

Reply via email to