incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <james.strac...@gmail.com>
Subject Re: Dynamic message selectors and message scheduling
Date Mon, 14 Aug 2006 07:17:19 GMT
On 8/13/06, Noel J. Bergman <noel@devtech.com> wrote:
> In the thread titled "RE: [Proposal] Blaze", James Strachan wrote:
>
> >  Noel J. Bergman <noel@devtech.com> wrote:
> > > Totally unrelated ... JMS has the ability to create a message filter,
> but
> > > one of the limitations is that the filter is applied when the receiver
> is
> > > created, rather than when a get operation is executed.  This makes sense
> for
> > > the push receiver case, but is limiting for the pull receiver case.
> Does
> > > AMQP have anything to say about this aspect of messaging, or does it
> stay
> > > strictly in the messaging provider space, and away from the client API?
>
> > Could you explain a little more about your use case - it sounds
> > interesting :). Do you only want to fetch a single message with a
> > different filter per message, or just change the fliter from time to
> > time. If its the latter then creating JMS consumers is pretty cheap &
> > you can use any JMS to do that. Though the former, there's no 'give me
> > a message using filter X' type operation.
>
> Sorry for the delayed response.  Been busy on many fronts.
>
> My particular use case involves selecting the next message in the
> destination whose scheduled time is less than or equal to now.  If there
> were a "now" operation available in the query language, I wouldn't have to
> change the selector, but the expression would still have to be constantly
> reevaluated.  And in that case, I'd want both pull and push behavior to be
> supported.

That should be pretty simple to add to the selector syntax via a NOW()
function (to avoid 'NOW' clashing with some property on the message).
Though the filter would have to be constantly re-evaluted as typically
the assumption is that a selector is true or false but doesn't change
its value over time


> One alternative is writing a broker to handle scheduling, which means
> posting all messages intended to be rescheduled to the broker, which would
> post them back when the schedule time occurs, thus handling scheduling in a
> similar manner to how MQ handles subscriptions.

Yeah - I think handling the scheduled publish of messages is probably
a better idea as its more powerful and flexible - and pretty easy to
do via a broker interceptor...

http://incubator.apache.org/activemq/interceptors.html

FWIW here's an open issue on ActiveMQ if you want to track its progress...

http://issues.apache.org/activemq/browse/AMQ-451

-- 

James
-------
http://radio.weblogs.com/0112098/

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message