[Twisted-Python] Re: CLOSE_WAIT (debian)

Josef Novak josef.robert.novak at gmail.com
Thu Jun 5 04:25:25 EDT 2008


Hi, I've been digging around a bit more and it seems like it might be
advisable for me to use the d.setTimeout(TIMEOUT) function for my
deferToThread objects.  I see from the docstrings that this is
deprecated, and that I should rely on the timeout mechanism supplied
by the API I'm using, however that doesn't seem to suggest an
immediate solution.  I dug up the following reference, but is it
really such a bad idea to use d.setTimout(TIMEOUT)?
http://twistedmatrix.com/pipermail/twisted-python/2004-April/007536.html

Thanks!

2008/6/5 Josef Novak <josef.robert.novak at gmail.com>:
> Hi,
>  I have a fairly simple twisted daemon based on the starpy protocol,
> which I am running in combination with the asterisk pbx.  I sometimes
> this daemon accumulates CLOSE_WAIT connections in a rather
> unpredictable fashion, which when stacked up eventually cause the
> daemon to stop responding to new connections.
>
> My understanding is that there is no default timeout for the
> CLOSE_WAIT socket state, as per the relevant rfc standard, and that in
> any netstat declares that CLOSE_WAIT indicates that the remote end of
> the connection has shut down, and that it is now up to the local
> application to finish closing the socket.
>
> The implication is that there is something wrong with my application
> code, however before posting the whole thing I'd like to know if there
> are any cannonical reasons for this kind of issue being raised in
> twisted applications.  For instance is this likely to occur when one
> uses defertothread for blocking third party code, and the child
> process spawned to handle this returns to find the parent process
> already gone? ( e.g. my twisted app spawns for a new call from
> asterisk, but the call instance is destroyed for some reason before
> the defertothread that it executes returns?)
>
> I'm having trouble reliably causing the issue, but it continues to pop
> up, so any general information about regarding debugging twisted
> applications would be of help.
>
> Thanks!
>




More information about the Twisted-Python mailing list