Container-based scheduling

["Noel J. Bergman" <no...@devtech.com>]

> > On a related note, as I believe I've mentioned I'd like to change the
way
> > that RemoteDelivery works.  Rather than have RemoteDelivery handle its
own
> > queuing, I'd like to push that out a level so that any matcher/mailet
can
> > benefit from that capability.  For example, if a DNSRBL matcher failed,
the
> > operation could be requeued.

> I would not mind putting that on my list

Let's agree that the "lists" we're putting into the Wiki are communal.  I
put them in as "X's list" just make it easier for folks to find and merge
(because I was too lazy to do that myself), not to imply ownership.  If I
were to say that something is on my list, it would be because it is
something I'm interested and/or willing to do, not something I feel is mine
to do.  Right?  :-)

> most stuff that concerns RemoteDelivery has my interest ;-)

:-)

> Do you have more detail of how you envision this requeing service?

I had started playing with an AbstractSpooled mailet, which was derived from
the RemoteDelivery mailet, factoring out all of the generic code from the
delivery-specific code.  The obvious quickly became apparent: what you end
up with is wanting to retry/schedule calls to the service method, and this
ought to be available to both matchers and mailets.  Plus, we want to be
able to use a pool of workers.

My thought is to incorporate it directly within the container (Processor --
whether or not that is a special mailet type is orthogonal).  We would need
a means by which the matcher or mailet can indicate the need for a retry,
but the schedule would be configured in the container.  For a mailet, we
COULD have a magic RETRY state, just as we have a GHOST state, but the
matcher interface doesn't support that approach.

A better idea, I feel, might be to use something like:

  package org.apache.mailet;
  class RetryException extends javax.mail.MessagingException { ... }

That would handle both matchers and mailets, and we could put useful
information into the exception, such as the reason for the retry.  For that
matter, we could allow some retry information to be provided.  I'm still
thinking that as a general rule, the schedule ought to be configured
external to the matcher/mailet, but can imagine that in some cases the
matcher or mailet will have better information, particularly if the
scheduling is dynamic.

	--- Noel


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org