On 14/01/14 14:27, Dustin J. Mitchell wrote:
There are two things wrong with your scenario.
First, in any production or production-ready environment, your
software needs to correctly handle stuck TCP connections. With the
proliferation of "smart" network equipment (session-tracking
firewalls, etc.), this is much more common than it was five or ten
years ago. Some DBAPI backends are better about this than others -
for example, MySQL-Python gets it right, but PyMySQL does not.
That is certainly a fine sentiment with which I agree in principle, but
an ENORMOUSLY LARGE amount of (really very expensive and business
critical) software doesn't handle this *at all* as anyone who runs a
firewall in front of an e-Business app can tell you.
[A well known vendor whose name rhymes with a type of traditional small
boat used extensively in the British Isles is a particular offender]
So if you're handling this correctly, give yourself a pat on the back -
there is software costing millions a year in licence fees that assumes
TCP is as reliable as CPU->CPU cache communications :o(
Second, this has nothing whatsoever to do with whether the I/O is
blocking or not. Twisted apps can and, believe me from experience, do
suffer from stuck TCP connections. Sure, the wasted resources in this
case are smaller (just a file descriptor, not a thread), but the user
experience is the same (part of the application hangs irreversibly).
In fact, this is about the only thing the manhole is used for at
Mozilla: running `os.close` on stuck fd's.
I'm wondering if TCP keepalive isn't any use to you in this regard?
(and what do Mozilla do with Twisted? :o)
_______________________________________________
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
