[Twisted-Python] ReconnectingClientFactory creates multiple Protocols?
Hello -- My network app consists of a ReconnectingClientFactory whose Protocol instances connect to a another server. The protocol class logs its activities to a file. Each transaction has a unique number that increments. As far as I can tell, it works perfectly, with one strange quirk. If I leave the app running for several days, I start seeing more than one protocol showing up in the logs. I can tell that it's not the same protocol since there's more than one sequence of transaction numbers incrementing. As far as I can tell, it's related to the connection being dropped, at which point the Factory reconnects and creates a new protocol instance. What might I be doing wrong? It's buildProtocol() that creates the new instances, but shouldn't the previous instance get disconnected and cleaned up somehow? How can I ensure this? Is it possible to force a protocol to disconnect and get deleted? Which class (app, service, factory, protocol) should be responsible? Thanks in advance, mikah
On Thu, 2005-09-15 at 13:32 +0800, mikah@ceruleansoftware.com wrote:
Protocols (at least, when used with TCP) are designed so that their lifetime matches that of the TCP connection they are handling. As a result, when the connection is lost and the factory reconnects, this is a new TCP connection with a new protocol. This is why there's a factory, to manage data and logic that is not tied to a specific TCP connection (e.g. "should I reconnect?" or "how far along was the download when I got disconnected.") In general you'd want to use the factory to store state that needs to last past the lifetime of the protocol. You can, of course, have buildProtocol always return the same instance, but that's pretty ugly and can easily lead to obscure bugs if you don't clean up the state correctly.
On Thu, 2005-09-15 at 13:32 +0800, mikah@ceruleansoftware.com wrote:
Protocols (at least, when used with TCP) are designed so that their lifetime matches that of the TCP connection they are handling. As a result, when the connection is lost and the factory reconnects, this is a new TCP connection with a new protocol. This is why there's a factory, to manage data and logic that is not tied to a specific TCP connection (e.g. "should I reconnect?" or "how far along was the download when I got disconnected.") In general you'd want to use the factory to store state that needs to last past the lifetime of the protocol. You can, of course, have buildProtocol always return the same instance, but that's pretty ugly and can easily lead to obscure bugs if you don't clean up the state correctly.
participants (2)
-
Itamar Shtull-Trauring -
mikah＠ceruleansoftware.com