Opened 17 years ago
Last modified 17 years ago
#22 new defect
log NegotiationErrors better
Reported by: | Brian Warner | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | undecided |
Component: | negotiation | Version: | 0.1.6 |
Keywords: | Cc: |
Description
We need better logging of NegotiationErrors? and other connection failures:
- Each connection failure should log which TubID we were trying to connect to and the connection hint it was using
- each reconnector-tracked disconnect should announce how long it will be until the next connection attempt
- when a Negotiation rejects the initial GET because it was for an unknown TubID, consider putting the list of known TubIDs in the error message (if it is short).
The use cases for this logging:
- someone provides the wrong hostname to a Tub.setLocation, causing it to emit FURLs with a bad connection hint. When clients use this FURL, they connect to the wrong host/port. One of three things happens:
- the port has nothing on it, causing a ConnectionFailed? error
- the port has a non-Foolscap server on it, most likely causing a protocol error in the Negotiation phase
- the port has a Foolscap server without the desired TubID on it, causing a "not right" error during Negotiation
- in all three cases, there should be enough information in the logs to locate the bad FURL.
- when one of these bad FURLs is used in a Gift, the log message is emitted on the far end of the wire, but the NegotiationError? probably shows up in the errback returned to the sender of the gift.
Note: See
TracTickets for help on using
tickets.