Opened 15 years ago

Last modified 11 years ago

#1955 defect new

— at a forgotten resetTimeout in twisted.protocols.postfixVersion 9

Reported by: quakelee Owned by:
Priority: low Milestone:
Component: core Keywords:
Cc: jesstess, Thijs Triemstra Branch: branches/postfix-timeout-1955
branch-diff, diff-cov, branch-cov, buildbot
Author: jesstess

Description (last modified by Jean-Paul Calderone)

I think after sent code to client, daemon should reset timeout. If data source is a big and slow object, getting and sending result to client may consume a lot of time, if you didn't reset the timer, the connection maybe lost before client reply to daemon.

--- postfix.py.orig     Tue Jul 25 00:57:49 2006
+++ postfix.py  Tue Jul 25 01:08:13 2006
@@ -48,6 +48,7 @@
     def sendCode(self, code, message=''):
         "Send an SMTP-like code with a message."
         self.sendLine('%3.3d %s' % (code, message or ''))
+        self.resetTimeout()
 
     def lineReceived(self, line):
         self.resetTimeout()

Change History (10)

comment:1 Changed 15 years ago by quakelee

I think after sent code to client, daemon should reset timeout. If data source is a big and slow object, getting and sending result to client may consume a lot of time, if you didn't reset the timer, the connection maybe lost before client reply to daemon.

comment:2 Changed 15 years ago by Jean-Paul Calderone

The server should actually be disabling the timeout before it begins any long response and re-enabling it after it has completely finished sending it. Resetting the timeout afterwards is insufficient, since the timeout may occur before the send even finishes.

Changed 15 years ago by quakelee

Attachment: patch-postfix.py added

patch of postfix.py

comment:3 Changed 15 years ago by quakelee

In our enviroment, we use the ldap server as a data source. Unfortunately, the ldap server not very stable. Sometimes it can query very fast, but sometimes maybe consume a longtime. So we add a resetTimeout to prevent unexpected lost connection.

BTW: we discuss the problem about how to deal connection when daemon meet a error have to reply 400 to client with the inventor of postfix tcpmap. After discussion we think we should close the connection directly instead code 400. If do that, postfix will retry it.

comment:4 Changed 15 years ago by quakelee

In the other hand, If some people want to shorten the timeout time, I think reset timeout after sending code is more important than it is 600s or longer.

comment:5 Changed 13 years ago by Glyph

Owner: changed from Glyph to quakelee

Thanks for your contribution. Sorry we've been so long in getting to it. Please see the TwistedDevelopment page on the wiki for guidelines on how to get a more prompt response.

Please note that this patch will need test coverage in order to be accepted. I hope you will add some and submit it for review!

comment:6 Changed 12 years ago by jesstess

Author: jesstess
Branch: branches/postfix-timeout-1955

(In [28108]) Branching to 'postfix-timeout-1955'

comment:7 Changed 12 years ago by jesstess

(In [28109]) Disable the timeout in sendCode before calling sendLine and re-enable it afterwards to avoid timing out while the server is sending a status message.

refs #1955

comment:8 Changed 12 years ago by jesstess

Cc: jesstess added
Keywords: review added
Owner: quakelee deleted

comment:9 Changed 12 years ago by Jean-Paul Calderone

Description: modified (diff)

fixing description markup

Note: See TracTickets for help on using tickets.