james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Soeren Hilmer <soren.hil...@tietoenator.com>
Subject Re: RemoteDelivery progressively increasing delay-time
Date Fri, 03 Oct 2003 09:27:50 GMT
Noel gave a reference to RFC-2821 which basically explains this need.

It is often observed that servers not responding will do so shortly after, and 
if not they will probably not respond until very much later (if at all), so 
if multiple delay times are given James can use a more optimal delivery 
strategy, which will save on system resources. 

Consider these which are your options with one delay:

i) We want to deliver the mail as fast as possible, so we set a small 
delaytime, and because we want to keep going until maybe 5 days, the 
maxRetries needs to be high. If the mail cannot be delivered this results in 
RemoteDelivery needing to timeout many times, tying up one of the delivery 

ii) We do not care about the mail being delivered promptly, so we set a large 
delaytime and a small maxRetries. This basically leeds to no problems, aside 
from users waiting for their mails and calling the helpdesk, which ought to 
be considered bad.

Because of the fact that servers are observed to often reply shortly after a 
timeout, James ought to do its best to deliver the mail promptly without 
sacrificing its own resources to much. The strategy with multiple delay times 
is a fairly good way to achieve this.


On Friday 03 October 2003 11:07, David Liles wrote:
> Why is it necessary to have a list of delay times to iterate through?
> Wouldn't it be simpler to just have a single delay time setting with the
> number to times to attempt to redeliver?
> -----Original Message-----
> From: Soeren Hilmer [mailto:soren.hilmer@tietoenator.com]
> Sent: Friday, October 03, 2003 3:40 AM
> To: James Developers List
> Subject: Re: RemoteDelivery progressively increasing delay-time
> Hi,
> I do not really know how this process works, who has the final word on
> which of the proposed ways to do this, we go for?
> I like Serge's "attempts" version best, but in this case are maxRetries
> then to be disregarded? Or is it to be used on the last delaytime entry, if
> the attempts attribute is missing? (assuming that attempts defaults to 1 if
> not specified) As this last version is the most versatile, I believe this
> is the route to go.
> I would like to start on this monday, so ...
> --Søren
> On Thursday 02 October 2003 19:38, Serge Knystautas wrote:
> > Soeren Hilmer wrote:
> > > I have been thinking about extending RemoteDelivery to take a list of
> > > delaytimes.
> > >
> > > Something like:
> > > <delayTime> 600 </delayTime>
> > > <delayTime> 1600000 </delayTime>
> > > <delayTime> 21600000 </delayTime>
> > > <delayTime> 21600000 </delayTime>
> >
> > I like this, but would suggest an attribute named "attempts" to each
> > element.  For example, <delayTime attempts="3"> 600 </delayTime> would
> > try 3 times at 600ms delays before moving to the next delayTime element.

Søren Hilmer, M.Sc.
R&D manager		Phone:	+45 70 27 64 00
TietoEnator IT+ A/S	Fax:	+45 70 27 64 40
Ved Lunden 12		Direct:	+45 87 46 64 57
DK-8230 Åbyhøj		Email:	soren.hilmer@tietoenator.com

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

View raw message