Hi Norman, Norman Maurer wrote:
> > Maybe we should change our accept order policy: now we sort by > > last_updated. Maybe we should change it to sort by state then > > last_updated (getting first all the messages not in ERROR and then the > > one in ERROR). This way at least a first attempt should always be done > > with a grater priority than retries. > At the first moment that seems a good idea.. But after thought a bit > about it i think that can cause problems too! What will happen if we > have a very big mailload which inject many mails per seconds? This will > block delayed mail for the whole time. That is not good IMHO.. But in that situation you will always have mails that are not delivered until the load gets reduced. If you first deliver the "fresh" ones you can deliver overall more messages instead of "wasting time" with messages that maybe will fail forever. Users rely on very fast email communication, normaly it should work like IM. The great majority of mails will pass through within seconds. So why don't let them go? I really like Jerry's idea of the "slow driver lane". The normal/fast threads could even work with very short timeouts for the first delivery, e.g. 10 seconds. The majority will just get delivered at once. So there won't be a situation where the majority of the users can't work because a minority of the mails fail. Priorization should be: 1. new mails, 2. mails that failed once, 3. mails that failed twice... It's just pragmatic. In situations of horrible loads where the spool is full of retry messages there should be a dead line. I personally would prefer a mail gets bounced after 24h/48h hours. The user then can decide whether to send again or choose another communication method. Joachim --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
