activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Bertram <>
Subject Re: Ring buffer with Artemis: paging mode
Date Mon, 01 May 2017 23:09:12 GMT
Couple of things:

  1) Paging should really be considered palliative. In other words, it's just meant to mask
the fact that the broker has run out of memory. Performance will drop considerably when paging.
You can certainly rely on it to do its job (i.e. keep the broker from crashing while steps
are taken to restore message flow and/or client performance to normal levels). However, it's
not something I would really recommend building a solution to specifically leverage. Lots
of users think paging is kind of a general use feature rather than a palliative and therefore
build solutions to use a message queue like a database. This is a classic anti-pattern [1].
I'm not saying you're guilty of this; I'm just trying to be clear.

  2) You have observed correctly that dropping messages is supported when an address reaches
its memory limit, but only blocking is supported when the broker reaches its disk limit.

  3) Retroactive consumers are not implemented.



----- Original Message -----
From: "Victor" <>
Sent: Monday, May 1, 2017 4:06:21 PM
Subject: Re: Ring buffer with Artemis: paging mode

Sorry, forgot to mention that I was planning to combine it with retroactive
consumers too, but the only thing I can find is inconclusive:

2017-05-01 14:04 GMT-07:00 Victor <>:

> Hi all,
> I have been considering to implement something similar to a ring buffer
> with artemis to deliver server metrics to a number of backends:
> I was hoping to be able to:
> - have a topic √
> - limit paging with a max disk usage √
> - drop messages when the disk page limit is reached ?
> - higher priority for metric messages coming from the serves where the
> brokers run √
> Doing a quick review and google search I can't find other people having
> similar experiences.
> I also find that I can only drop messages the memory limit
> <> is reached,
> not the disk limit.
> Any ideas?

View raw message