On 8/13/06, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
In the thread titled "RE: [Proposal] Blaze", James Strachan wrote:
> Noel J. Bergman <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
