incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <>
Subject Re: Dynamic message selectors and message scheduling
Date Mon, 14 Aug 2006 07:17:19 GMT
On 8/13/06, Noel J. Bergman <> wrote:
> In the thread titled "RE: [Proposal] Blaze", James Strachan wrote:
> >  Noel J. Bergman <> 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...

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



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message