OK, please see this jira ticket and vote for it!
https://issues.apache.org/jira/browse/AMQ-5522
Please make comments in the ticket, or let me know, if any updates to the
ticket are desired.
--
View this message in context:
http://activemq.2283324.n4.nabble.com/How-to-limit-queue-depth-by-msgs
Yes, that¹s my intent. Keeping bad behaving producers/consumers from
affecting time critical messages/queues.
The memory limit per queue is really only applicable when vm-cursor is
used. If a store cursor is used (which is almost the only option on high
volume, low memory systems), then data is sw
I can't speak to Petter's scenario, but in my use case that's the intent:
we don't want to allow an infinite number of messages to build up on the
broker. But the slow consumer abort strategy is also a part of the
protection strategy for the broker (since we primarily use topics with
non-durable s
That's an interesting requirement. The memory usage limit is there to help
ensure the broker's resources are not exhausted.
Is the end intent the same in using a message count?
--
View this message in context:
http://activemq.2283324.n4.nabble.com/How-to-limit-queue-depth-by-msgs-tp4689633p46
Tim,
Thanks for the reply. Prefetch is not really a problem, since in this
scenario I tend to use 1 as reliability is the only concern, not
performance in this case.
Number of messages is sometime a better measurement than memory, and a
more valid constraint. It¹s easier to cope with a requirement
Petter,
I'm not aware of a way to limit queue depth by number of messages that will
invoke producer flow control, which is the behavior I assume you want to
result when you hit the limit. We actually just disabled per-destination
memory limits in our broker because of the difficulty of guaranteei
