En Wed, 12 Dec 2007 20:12:43 -0300, Object01 [EMAIL PROTECTED] escribi�:
I don't know much about the timing of Python's garbage collection. Is
it pretty aggressive?
As soon as the reference count reaches zero (at least for current CPython
version). Objects that are part of a reference cycle
On Dec 11, 6:17 pm, Gabriel Genellina [EMAIL PROTECTED]
wrote:
En Tue, 11 Dec 2007 10:51:13 -0300, Object01 [EMAIL PROTECTED] escribi�:
I've been working with the source code for Trac (http://
trac.edgewall.org/) lately and have run across a bizarre problem. It
seems that all POST
Gabriel Genellina wrote:
A RST when you close a socket is OK.
Says who? MS? ;)
Regards,
Björn
--
BOFH excuse #328:
Fiber optics caused gas main leak
--
http://mail.python.org/mailman/listinfo/python-list
Object01 wrote:
The server is multithreaded, handling each request on its own
thread.
Ugh.
But is a RST really a part of a valid close operation?
Depends on the state of the parties :) The proper way to close
non-defunct connections is using FIN segments.
It was my understanding that the
On Dec 12, 12:45 pm, Bjoern Schliessmann usenet-
[EMAIL PROTECTED] wrote:
Object01 wrote:
The server is multithreaded, handling each request on its own
thread.
Ugh.
But is a RST really a part of a valid close operation?
Depends on the state of the parties :) The proper way to close
Do you have any non-standard network hardware along the route? Perhaps a
transparent proxy like a load balancer or a firewall of sorts? I've seen
this type of thing happen before with load balancer gear. In my situation,
I had a load balancer that kept a state table. If the load balancer didn't
En Wed, 12 Dec 2007 15:46:14 -0300, Bjoern Schliessmann
[EMAIL PROTECTED] escribió:
Gabriel Genellina wrote:
A RST when you close a socket is OK.
Says who? MS? ;)
Nevermind... just nonsense!
--
Gabriel Genellina
--
http://mail.python.org/mailman/listinfo/python-list
En Wed, 12 Dec 2007 13:38:21 -0300, Object01 [EMAIL PROTECTED] escribió:
On Dec 11, 6:17 pm, Gabriel Genellina [EMAIL PROTECTED]
wrote:
En Tue, 11 Dec 2007 10:51:13 -0300, Object01 [EMAIL PROTECTED]
escribi�:
I've been working with the source code for Trac (http://
trac.edgewall.org/)
Is this applicable in your
case?:http://brad.livejournal.com/2152593.html?thread=10832273#t10832273
(closing a nonblocking socket with a nonempty output queue generates a RST)
Based on my stepping through the code, everything passed to
_fileobject.write() makes it out onto the wire just fine.
Object01 wrote:
Is there something I can look for in the packet traffic that would
indicate one party is misbehaving? The sequence numbers seem ok.
*shrug* I'd expect to see data sent from server to client and
then see a sequence of packets that close the connection
gracefully. Instead I
I've been working with the source code for Trac (http://
trac.edgewall.org/) lately and have run across a bizarre problem. It
seems that all POST requests to Trac's standalone server (tracd) have
a random chance of causing the server to issue a TCP RST packet that
resets the connection.
Running
En Tue, 11 Dec 2007 10:51:13 -0300, Object01 [EMAIL PROTECTED] escribi�:
I've been working with the source code for Trac (http://
trac.edgewall.org/) lately and have run across a bizarre problem. It
seems that all POST requests to Trac's standalone server (tracd) have
a random chance of
12 matches
Mail list logo
