Re: partially durable queue?

2018-01-26 Thread Noel Grandin
On 26 January 2018 at 20:58, Clebert Suconic 
wrote:

> 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?

2018-01-26 Thread Noel Grandin
On Fri, 26 Jan 2018 at 19:22, Tim Bain  wrote:

>
> 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?

2018-01-26 Thread Noel Grandin
On Fri, 26 Jan 2018 at 17:59, Justin Bertram  wrote:

>
> 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?

2018-01-26 Thread Noel Grandin


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