The original message is delivered and persisted as normal. The exchange would hold onto a copy of that message, and generate an entirely new, identical one at the specified interval.
Putting this logic at the exchange level seems better to me because it avoids further complicating the subscription implementation. It'll also map a bit cleaner into 1.0 semantics (as a non-destructive link). On 11/7/09, Robert Greig <robert.j.gr...@gmail.com> wrote: > 2009/11/7 Robert Godfrey <rob.j.godf...@gmail.com>: >> It would seem to me that it would be better for this use-case to instead >> implement something more analogous to time-to-live... only rather than >> that >> signaling the time at which the message would be archived it would signal >> the time at which the message becomes available for consumption. I'm not >> too keen on Exchanges that hold on to messages... > > Yes, I agree. How would you handle persistent messages if you hold > them at the exchange? > > RG > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:dev-subscr...@qpid.apache.org > > -- Sent from Google Mail for mobile | mobile.google.com Apache Qpid - AMQP, JMS, other messaging love http://qpid.apache.org "A witty saying proves nothing" - Voltaire --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
