Hi Noel,
Nice proposal. I have questions about the 'big picture':
Although I understand that you say the Scheduler is working with the
RemoteDelivery, is this a proposal to either
o replace RemoteDelivery or greater parts from it in short term
o take one aspect of RD and make it available in another context
o establish a parallel approach which is intended to replace RD when
time is due?
You say "New approach to spooling". How does the proposal affect
spooling 'in general'?
How is this related to past propositions (IIRC) to evolve RD from a
mailet to something better, e.g. an own processor?
I support any effort to forster 'seperations of concerns' so I should
be fine with the proposal in any case.
Thanks,
Bernd
On 8/20/06, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
I have a really busy couple of weeks in front of me, but once that is done,
I should have time to work on this for v3.0.
This is an approach to implement the scheduling aspect of my "New Approach
to Spooling" proposla. It is intentionally compatible with the existing
Mailet API.
The change will consist of three parts: a processor, a mailet and a utility
class. The processor would be defined, to use a simplified example without
configuration options, as:
<processor name="SCHEDULER">
<mailet class="Scheduler"/>
</processor>
which does nothing for you unless you know what the Scheduler mailet is, how
messages get there, and where they go afterwards.
The Scheduler mailet will be derived from the part of RemoteDelivery that
receives a message on a spool thread, and has a separate thread processing
an internal queue. We won't need more than one scheduler thread. When a
message's schedule time occurs, the mailet will post it to the designated
destination.
The utility class will contain the actual scheduler, whose core pseudo-code
can be described as:
schedule.retry(mail)
boolean scheduled = false;
retries = getRetryCount(mail);
if (retries < getMaxRetries()) {
setRetryTime(mail) { mail.setAttribute("org.apache.james.RETRY_TIME",
nextTime(mail)); }
setRetryCount(mail) {
mail.setAttribute("org.apache.james.RETRY_COUNT", ++retries); }
// WARNING: THESE TWO OPERATIONS MUST BE PERFORMED IN THIS SEQUENCE
SINCE BOTH DEPEND UPON THE MAIL'S STATE
setRetryDest(mail) { mail.setAttribute("org.apache.james.RETRY_DEST",
mail.getState()); }
setScheduler(mail) { mail.setState(schedule_processor); }
scheduled = true;
}
return scheduled
The code looks at the message, decides if there are more retries available,
and if so posts the message so that the scheduler knows when to post it
back, and to which processor. Yes, the rescheduling would be on a processor
boundary, which will be the transaction boundary once we properly support
transactions.
The schedule object would be constructed from a retry schedule such as the
one we have for RemoteDelivery. Actually, I'll do an abstract class with
the code for scheduling and an abstract method "nextTime" method, and then a
specific implementation making use of the code from RemoteDelivery, to
separate mechanics from policy. RemoteDelivery would receive messages and
perform something like:
if (!deliver(mail) && !schedule.retry(mail)) {
process a bounce
}
Other mailets, such as ClamAV, could contain similar code to schedule
retries if a resource they need is not available (and optionally notify the
administrator of the problem). Additional work will be done to allow
matchers to also rescheduling.
Comments solicited. This is just a first out.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
