[SERVER-40583] Provide reason for why connections are closed Created: 11/Apr/19 Updated: 08/Jan/24 Resolved: 08/Jul/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | 4.0.9 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Oleg Pudeyev (Inactive) | Assignee: | Benjamin Caimano (Inactive) |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | neweng | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||
| Sprint: | Service Arch 2019-05-06, Service Arch 2019-05-20, Service Arch 2019-07-15 | ||||||||||||||||||||
| Participants: | |||||||||||||||||||||
| Description |
|
Currently, when a server closes connections, it sometimes provides a reason why it does that, and sometimes does not. SERVER-39941 provides an example when the server does indicate the reason for closing a connection:
In cases like |
| Comments |
| Comment by Benjamin Caimano (Inactive) [ 08/Jul/19 ] |
|
Alright, marking this as a duplicate then. Thanks oleg.pudeyev for getting back to me on this long in the tooth ticket. |
| Comment by Oleg Pudeyev (Inactive) [ 08/Jul/19 ] |
|
This appears to satisfy the request in this ticket: > Since 4.0.10/4.1.3, we always log at D2 why connections close except when repl or FCV trigger terminate. |
| Comment by Benjamin Caimano (Inactive) [ 02/Jul/19 ] |
|
Since 4.0.10/4.1.3, we always log at D2 why connections close except when repl or FCV trigger terminate. Those should be pretty noisy spots in the logs. (For D2 logging, see here and here.) oleg.pudeyev, your reading of the spec is correct, we close the socket on you, which is a network error on client side, and thus the host is UNKNOWN. In the case of a network error on the server side, obviously we can't do much. We theoretically hang up on TransportLayer::TicketSessionClosedStatus, but that isn't a real thing. That leaves the case of "Interruptions" which pretty much means shutdown as far as I can tell. We could theoretically wait around for one more command and then respond {okay: 0}, but that is contrary to the "exit hard" philosophy of mongo-server. I'm not certain what more we can offer in terms of diagnostics on the server side. If you have concrete suggestions, I'm all ears. |
| Comment by Benjamin Caimano (Inactive) [ 02/Jul/19 ] |
|
In the case of |