Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
From: "Noel J. Bergman" <noel@devtech.com>
To: <general@incubator.apache.org>
Subject: RE: Dynamic message selectors and message scheduling
Date: Mon, 14 Aug 2006 18:29:48 -0400
Message-ID: <NBBBJGEAGJAKLIDBKJOPOELKJNAC.noel@devtech.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Importance: Normal
In-Reply-To: <ec6e67fd0608140017i7f117d16s681bc310633c13b1@mail.gmail.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