Honestly, that doesn't sound reasonable to me. ActiveMQ has no solid way to know which messages *should* or *should not* reach their destination before the TTL expires. That would require some feedback from across the broker-to-broker connection so the sending broker could take that into account. In addition, JMS has ordering guarantees (although it's never wise to fully depend on them).
The problem set sounds interesting - almost like ActiveMQ is being used as a throttle for network traffic. Anyway, how about altering the message TTLs plus or minus the maximum expected network latency times two? Either using randomness or simply alternating between + and -. In that way, some messages will still survive the trip while others don't when the backlog of messages reaches that critical point. And, some (most?) should expire before hitting the wire, saving that wasted trip. -- View this message in context: http://activemq.2283324.n4.nabble.com/ActiveMQ-stops-delivering-messages-to-consumers-when-saturating-a-high-latency-network-link-tp4685557p4685951.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
