Nick Barcet wrote:
> a) the queue must guaranty the delivery of messages. > To the contrary of monitoring, loss of events may have important billing > impacts, it therefore cannot be an option that message be lost. I don't think absolute reliability is desirable for this application. SCTP partial reliability may be a better model. Ultimately, full reliability requires the ability to block new messages from being produced. In the context of billing, that would mean that a failure of the billing system to consume its messages would result in stopping new services from being provided. Obviously you want to avoid that, but if the billing system fails do you want to stop providing services as well? You get no billable time in either case, but I think providing services without metering for billing will keep your customers so that you can bill them for their usage after you have restarted the billing system. A partial reliability system would provide a finite amount of storage for in-flight messages that probably should be configured for something Like3x the longest anticipated failure by the consuming entities to drain the queue. And it should guarantee that there will be no loss of Messages without an explicit exception being produced (somethink like "EMERGENCY: 2000 billing messages just erased. Interim storage is fully committed. Where is the consumer?") _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
