Re: partially durable queue?
On 26 January 2018 at 20:58, Clebert Suconicwrote: > With artemis you can simply disable syncs on producer and you would get > similar performance numbers. Usually people turn of persistence to gain > Ah, it's not perf I'm after, think of this as a kind of IOT/sensor device, I want to preserve my rather cheap SSD device from wearing out. I'm producing a number of measurements on 24/7 basis (10-50 messages / sec) In the common case I should be able to stream this out without ever hitting disk, but for backup I need to spool messages if the consumer becomes temporarily unreachable. This is an abnormal use-case, so I'm not surprised it's not readily available. But I figured (a) I might get lucky (b) if not, it might be worth adding the feature to ActiveMQ myself to avoid re-inventing all the other parts
Re: partially durable queue?
On Fri, 26 Jan 2018 at 19:22, Tim Bainwrote: > > 5.x can also do in-memory-till-full-then-spool-to-disk when using > non-persistent messages (which go to the memory store and then to the temp > store if the memory store is full). > That’s useful info thanks. But non persistent means that the broker will throw away the messages on a reboot? Which wouldn’t be good for me. I can lose a small window of data, but if the wan disconnects for a while and then the machine reboots I need to keep most of the data. >
Re: partially durable queue?
On Fri, 26 Jan 2018 at 17:59, Justin Bertramwrote: > > If you're asking about ActiveMQ, can you clarify if you're asking about the > 5.x or Artemis broker? > I’ve only just started looking at tech options, so I don’t even know what those are. I assume different forks of active mq?
partially durable queue?
Hi I have a need for a queue that operates purely in-memory until the consumer(s) can't keep up, and only then starts spooling to disk. I'm ok with losing some messages in the event of a hardware or software crash. Is there such a configuration in RabbitMQ? If not, could one be created with a plugin? For context, the requirement is slightly weird in that I'm (a) wanting to push some data back over a flakey WAN (b) from an underpowered piece of hardware that doesn't like it's little SSD drive being written too hard :-) Thanks, Noel Grandin