I'm not sure I can do anything to help you guys resolve this, but FWIW here's my view. I do not think that a scheduler is an appropriate solution for implementing a connection timeout. I was surprised when Shilpa first incovered this how inefficient it was. Apart from the issue of running out of memory, the core mechanism necessitates adding a new event object to a list every time the trigger is reset and its eventual removal and garbage collection. I do not think this is good design for a scalable, enterprise quality mail server and I think that Peter has made effective arguments against this.
Regards Steve -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
