james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <n...@devtech.com>
Subject RE: RemoteDelivery progressively increasing delay-time
Date Thu, 02 Oct 2003 15:31:11 GMT
Søren,

It has been discussed before, but no one ever implemented it.  RFC 2821
section 4.5.4.1 discusses a similar strategy:

   Experience suggests that failures are typically transient (the target
   system or its connection has crashed), favoring a policy of two
   connection attempts in the first hour the message is in the queue,
   and then backing off to one every two or three hours.

It also says that:

   Retries continue until the message is transmitted or the sender gives
   up; the give-up time generally needs to be at least 4-5 days.  The
   parameters to the retry algorithm MUST be configurable.

So I agree on the idea to support progressive delay times.  The last time
should be applied for all further retries.  An RFC compliant configuration
might look like:

  <!-- 5 minutes -->
  <delayTime>   300000 </delayTime>
  <!-- 10 minutes -->
  <delayTime>   600000 </delayTime>
  <!-- 45 minutes -->
  <delayTime>  2700000 </delayTime>
  <!-- 2 hours -->
  <delayTime>  7200000 </delayTime>
  <!-- 3 hours -->
  <delayTime> 10800000 </delayTime>
  <!-- 6 hours -->
  <delayTime> 21600000 </delayTime>

  <maxRetries> 25 </maxRetries>

That provides a 5 day retry period, with 4 attempts in the first hour, two
more within the first 6 hours, and then every 6 hours for the rest of the
period.

That is quite likely the initial configuration I would test on my server.

	--- Noel


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


Mime
View raw message