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 swapped to disk. And you cannot really constraint a queue from using x MB/GB of store space. The storeUsageHighWatermark only consider global store usage at a single point. Calculating the actual store usage (on disk) for a certain queue is likely very hard, since you need to take into account messages blocking kahaDB transaction log files containing mostly consumed messages. A ²queue depth² limit would be an easy and store/cursor/persistent independent way to limit a producer to fill up the broker. It¹s also very easy to communicate this restriction to end users, i.e. ²We will buffer up to 10k messages for your queue, if you need more, then we need to implement the consumer as a high available solution to not risk other communication². BR Petter Den 2015-01-08 23:28 skrev artnaseef <a...@artnaseef.com>: >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-tp4 >689633p4689670.html >Sent from the ActiveMQ - User mailing list archive at Nabble.com.
