Steve Atkins wrote:
For example, a delay time of up to 2 seconds is probably pretty safe.
Many of the things you're going to want to do in that time will take
longer than that. There's a long tail, but I'd expect to see some
processing take a minute or more in rare cases.
There is definitely a long tail here. The cases will depend on how
these scripts are designed. If a script developer understands it
could be applied at DATA, he/she will improve it for speed. That is
what happen to us. An example script provided that illustrated word
list scanner reading off a text file, grew with popularity and their
word list file grew over time increasingly causing delays into the
minutes when large payloads were transferred. Greater client timeouts
drops and retransmits issues was a result. Improved updates of the
scanner moved the processing time into seconds by using caching,
memory map files, pre-compiling of words, etc.
No one wants long delays to causes problems.
What's the failure mode at that point in the transaction - are we
defending against a transport failure, or the client violating spec
with timeouts or...?
Two things IMV
- most clients do not wait 10 mins. Its much shorter. We see around
3-5 minutes.
- The realization DATA processing is the new and more desirable
"thing"
and we need standards "adjustments" in order to provide continued
consideration for the "old things" (legacy software).
Implementators simply need to be reminded that data processing time
should be as minimal as possible, but also not trust a SMTP
recommendation of 10 minutes to be universally followed when they
begin to implement more DATA processing work.
For us, to help enforce/control the issue, we added a sysop-definable
GlobalTimeOut with a default of 5 minutes for processing all
call-outs, hooks, shims, what have you.
--
Sincerely
Hector Santos
http://www.santronics.com