I think you need a pendngMessageLimitStrategy that sets pending messages limit to 0 so that the broker does not keep messages past the prefetch value. Once a slow consumers prefetch buffer is filled, messages will be discarded. Reducing the prefetch value (which will effect latency) could ensure that there is are a limited number of messages that can be pending on a blocked connection for a slow consumer.
On the cpp side, if the prefetched messages are delayed due to some sort of connection block (not sure how that happens btw) a low time to live (or message expiry) should ensure that stale data is not delivered to your listener or consumer. On 19 October 2010 17:37, Jim Lloyd <jll...@silvertailsystems.com> wrote: > We have AMQ client applications in C++ that only use topics, and for which > latency is more important than guaranteed delivery. If messages were > persisted in a database for a significant amount of time before they were > consumed by a slow consumer, that would introduce problems of the same > magnitude or worse than letting those messages be lost. > > For AMQ to work the way we want, there are two places where messages may > have to be explicitly dropped: the broker and the activemq-cpp. Ideally the > broker would be the place were messages are usually dropped, but if for some > reason the TCP connection begins to block, then the activemq-cpp library > would need to drop messages. Does the current implementation of activemq-cpp > do this? > > Can someone please provide a summary of how we should be configuring our > brokers, and the transport and topic URIs to obtain what we want? We're > currently using AMQ 5.3.1 but we'll probably upgrade to 5.4 soon so I am > happy to take recommendations specific to 5.4. > > Thanks, > Jim Lloyd > -- http://blog.garytully.com Open Source Integration http://fusesource.com
