twisted-trac
commented
7 years ago  |
@warner set owner to @warner @warner set status to closed |
|---|
In changeset 1f4a41d466e6f8645688aa7ec4fefc0eafe02822
#!CommitTicketReference repository="" revision="1f4a41d466e6f8645688aa7ec4fefc0eafe02822"
ClientService.whenConnected: add failAfterFailures=
If set to an integer N, the Nth connection failure will cause the
whenConnected Deferred to fail (with the same Failure as the endpoint.connect
reported). So setting it to 1 means the very first failure will be delivered,
setting it to 2 means the first failure is ignored but a second consecutive
failure will be reported, etc.
This allows applications to react differently to initial connection problems,
such as a DNS error, or a complete lack of internet connectivity. If the
first attempt fails, additional attempts are unlikely to do any better. For
some applications, silently re-attempting the doomed connection forever may
cause more confusion than simply emitting an error and terminating
immediately.
The default value (None) retains the current behavior of waiting forever (or
at least until the service is stopped).
closes ticket:9116
In Magic-Wormhole, when you run
wormhole send, the first thing it does is to spin up aClientServiceto manage the connection to our "rendezvous server". Once the connection succeeds, the automatic re-connection logic is perfect: the client can now tolerate the server getting bounced in the middle of a long-lived file-send operation. I'm super happy about this being available, as it replaced a lot of custom code in my app.However, the fact that it hides an initial failure is a bit of a drag. Most of the time, if the first connection fails, then it's unlikely that a second connection is going to succeed. We should really report this error to the user instead of silently trying again and again forever. Things like:
(I'm reminded of the Hitchhiker's Guide story about the cruise passengers held in suspended animation for centuries, awaiting civilization to be rebuilt and complete delivery of the refreshing lemon-soaked paper napkins)
What I'm thinking is an extra argument to
ClientService(), something likefailOnFirstError=True. If present, at startup the state machine is diverted to a separateconnecting_for_first_timestate, which behaves a lot like the normalconnectingstate except in how it reacts to a failure:cs.whenConnected()Deferreds get an errback with the actual connection failure (a ConnectionFailed of some sort)The Service remains "running" so that callers can call .stopService as usual, rather than an error quietly pretending to be the application and stop the service behind its back. The error is "sticky" so that a
.whenConnected()called after the error occurs can still see the error (instead of accidentally waiting for a new connection that will never come). This is especially helpful for errors that happen quickly (even synchronously) because the network is completely unavailable. Restarting the service will clear the sticky error.If we make it far enough to get a connection established, even once, then any failure past that point will trigger a reconnect as before. We might reconsider this if/when we implement the extra initialization function from #8375: maybe a failure of that function should inhibit reconnection too. E.g. if your IMAP login credentials are wrong, then retrying the connection isn't going to help.
I'm working on a branch for this, since otherwise I'll need to copy all of ClientService into magic-wormhole to make a private modified copy there. I'll add an update here when I've got some code to look at.
Searchable metadata
``` trac-id__9116 9116 type__enhancement enhancement reporter__warner warner priority__normal normal milestone__None None branch__ branch_author__ status__closed closed resolution__fixed fixed component__core core keywords__None None time__1492118429095682 1492118429095682 changetime__1493059079007089 1493059079007089 version__None None owner__Brian_Warner__warner_____ Brian Warner