the discarding policy is based on the prefetch being reached so it is independent of memory limits so long as there is sufficient memory to reach 2*prefetch.
have a peek at: org.apache.activemq.broker.region.TopicSubscription#add to see the full detail http://svn.apache.org/viewvc/activemq/trunk/activemq-core/src/main/java/org/apache/activemq/broker/region/TopicSubscription.java?view=markup On 29 August 2012 17:47, Steve Angelovich <sangelov...@lgc.com> wrote: > All, > > I have a situation where I'd like to discard non-persistent messages if > necessary. What I'd like to do is discard the oldest messages first for > slow consumers but only if needed. > > So far I've; > - turned off flow control > - set the memory limit in my default policy entry > - added a message limiting strategy > > Questions; > > Is setting the memory limit on the destinations a good idea if I'm using > some type of message eviction strategy? I don't know the number of > producers or consumers so I'm not sure how to specify this limit correctly. > > I'm using the ConstantPendingMessageLimitStrategy. Does this strategy > immediatly start evicting messages based on the limit or is the memory > limit of the destiation first taken into account? For example if I have > one very slow consumer but lots of memory available would it allow the > pending messages to grow beyond the limit I've specified. > > My broker is embedded so we don't ship the jars necessary for > persistence so I don't want overflow to be spooled to temporary disk. > Should I be specifying the VM cursors? > > > > Thanks, > Steve > > ---------------------------------------------------------------------- > This e-mail, including any attached files, may contain confidential and > privileged information for the sole use of the intended recipient. Any > review, use, distribution, or disclosure by others is strictly prohibited. > If you are not the intended recipient (or authorized to receive information > for the intended recipient), please contact the sender by reply e-mail and > delete all copies of this message. -- http://fusesource.com http://blog.garytully.com