[Twisted-Python] Re: ReconnectingClientFactory creates multiple Protocols? (clarification)

[Jp Calderone]

On Tue, 20 Sep 2005 15:36:18 +0800, mikah at ceruleansoftware.com wrote:
>Itamar Shtull-Trauring <itamar at itamarst.org> wrote:
>> mikah at ceruleansoftware.com wrote:
>> >   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.
>>
>> 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.
>
>Itamar,
>
>  Thanks for the reply. I think I have to clarify though, I
>wasn't very clear describing the situation -- my problem isn't
>that the RCFactory creates protocols on the fly, it's that
>after disconnecting/reconnecting, the old protocol instance
>seems to be still active! After the server has run a few days,
>I start seeing a handful of protocol instances. I know they
>aren't the same protocol because I can tell them apart from the
>data they write to the log file.
>
>  Only one of the protocols is actually connected to the remote
>host, that much I can say. It's the 'newest' one (I hope). The
>other instances are not connected but they attempt to send
>requests anyway, and worse, continue to pull tasks out of the
>task queue. So I end up with a bunch of tasks that never get
>acted on because the protocols can't service them without a
>connection.
>
>  My question is: when an RCFactory makes a new protocol
>instance, is the old one supposed to be deleted and cleaned
>up?
>
>  Everything hinges on this, pretty much. If the answer is yes,
>then I'm doing something wrong because mine aren't getting
>cleaned up. If the answer is no, then I must somehow take
>responsibility for preventing the old instances from trying to
>do work when they shouldn't, and somehow delete them.

To some minor extent, yes.  Completely and totally?  No.  For example, if you have a delayed call which invokes a method on the protocol instance, this will still occur.

>
>  I have some related questions if someone would like to answer
>them ... (1) is there a proper way for me to disconnect a
>connected protocol and then stop its factory from reconnecting
>and (2) start the factory connecting again at some time in the
>future?
>

When the connection is lost, "connectionLost" is called on the protocol and "clientConnectionLost" is called on the factory.  Use one or both of these hooks to clean up after your now defunct protocol.

Jp