You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by "Noel J. Bergman" <no...@devtech.com> on 2006/08/13 21:14:36 UTC
Dynamic message selectors and message scheduling
In the thread titled "RE: [Proposal] Blaze", James Strachan wrote:
> Noel J. Bergman <no...@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.
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.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Dynamic message selectors and message scheduling
Posted by Bruce Snyder <br...@gmail.com>.
On 8/14/06, Noel J. Bergman <no...@devtech.com> wrote:
...
> there seems to be an outstanding issue of there not being properly working
> XA transaction manager available as Open Source.
Excerpt from the JOTM website (http://jotm.objectweb.org/):
'15 February 2005: NOTICE
The JOTM Team has recently implemented XA Recovery in JOTM...'
See also: http://jotm.objectweb.org/license.html
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
Apache Geronimo - http://geronimo.apache.org/
Apache ActiveMQ - http://incubator.apache.org/activemq/
Apache ServiceMix - http://incubator.apache.org/servicemix/
Castor - http://castor.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Dynamic message selectors and message scheduling
Posted by "Noel J. Bergman" <no...@devtech.com>.
James Strachan wrote:
> Noel J. Bergman wrote:
> > 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).
Yes, I meant as a function ("operation"). Sorry for the shorthand without
the (). BTW where in the JMS Specification does it support custom functions
for selectors?
> 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
The assumption is that a selector's value would not change for a given
message so, as an optimization, one wouldn't have to reapply the selector
to a message already in the destination.
> > 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 I can start with a purely JDBC-based implementation, which would satisfy
my most pressing needs in a local clustering environment. As a side-effect,
an additional near-term upside would be avoiding the need for XA, since
there seems to be an outstanding issue of there not being properly working
XA transaction manager available as Open Source. Eventually, though, I'd
like XA across JMS, JDBC and Commons Transactions.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Dynamic message selectors and message scheduling
Posted by James Strachan <ja...@gmail.com>.
On 8/13/06, Noel J. Bergman <no...@devtech.com> wrote:
> In the thread titled "RE: [Proposal] Blaze", James Strachan wrote:
>
> > Noel J. Bergman <no...@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
Re: Dynamic message selectors and message scheduling
Posted by ro...@jpmorgan.com.
One option in AMQP would be to write a custom exchange to handle the
concept of delivery at a scheduled time. Exchanges are effectively an
extension point in the protocol so that you can customise delivery
algorithms.
The Glasgow broker currently doesn't have a well defined API to allow the
average end user to plug in new exchanges but this is definitely something
I think we will want to get to. Getting use cases such as yours definitely
helps us understand what type of thing users might want to be able to do in
an exchange.
Robert
"Noel J. Bergman"
<noel@devtech.com To: <ge...@incubator.apache.org>
> cc:
Subject: Dynamic message selectors and message scheduling
13/08/2006 20:14
Please respond to
general
In the thread titled "RE: [Proposal] Blaze", James Strachan wrote:
> Noel J. Bergman <no...@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.
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.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates.
This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org