qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Godfrey <rob.j.godf...@gmail.com>
Subject Re: qpid.periodic exchange type
Date Sun, 08 Nov 2009 17:15:09 GMT
2009/11/8 Aidan Skinner <aidan@apache.org>

> 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).
I don't think we would need to complicate subscription implementation unless
we wanted to implement this by having selectors which compared message
fields to the present time (or some other condition that would need to be
periodically reevaluated).  I was thinking that we would implement like TTL
- i.e. the message state on the queue is changed when the time-driven
condition changes (in this case when it becomes live)...  As happens already
in the queue, the state change will cause the subscribers to go re-examine
the message to see if they can now deliver it.  Other than sorting out how
we do timed events a bit, this seems like a fairly minor change at the queue

Having exchanges that retain state would be a big departure, and as Robert
points out would complicate persistence.  From a 1-0 point of view, there
will be no such thing as exchanges, so I'm not sure I really see the
advantage there.  Basically the difference is between hard-coding the entry
point/address for the message (by fixing the exchange type) or adding a new
capability to queues.  I much prefer the latter, and I also think it will be
cheaper to implement


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message