[SERVER-38681] Make it possible to have a TaskExecutor and ConnectionPool that don't auth Created: 17/Dec/18  Updated: 06/Dec/22  Resolved: 12/Nov/21

Status: Closed
Project: Core Server
Component/s: Networking
Affects Version/s: None
Fix Version/s: features we're not sure of

Type: Improvement Priority: Major - P3
Reporter: Mathias Stearn Assignee: Backlog - Service Architecture
Resolution: Won't Do Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-40580 Add a non-authing task executor to se... Closed
Assigned Teams:
Service Arch
Participants:

 Description   

The ReplicaSetMonitor should be running its isMaster calls on un-authed connections, but this isn't currently possible with a TaskExecutor.



 Comments   
Comment by Lauren Lewis (Inactive) [ 12/Nov/21 ]

We haven’t heard back from you for some time, so I’m going to close this ticket. If this is still an issue for you, please provide additional information and we will reopen the ticket.

Comment by Andy Schwerin [ 26/Dec/18 ]

I think putting the justification into the description would suffice. I'm interested further in the future in reducing the number of round trips to the first fully authenticated RPC in the common case, both to handle connection scaling and because I still believe in the dream of SERVER-12143, "Make some unauthenticated commands require auth", which includes an aspiration to get most of the ismaster data into post-auth variants of ismaster only. But that will take place in a future where we've had to more thoroughly reexamine how we handle authentication.

Comment by Mira Carey [ 20/Dec/18 ]

Because it has the option to (because the drivers do so), and because waiting for auth'd connections adds overhead in targeting that doesn't deliver any extra user value.

The pathological case is a replset with a newly elected primary on the opposite side of the earth (from our mongos). We're looking at 2x the round trips, so 2x the wait before we start establishing connections and servicing requests.

Round trips:

  • Tcp handshake
  • 2x tls establishment
  • isMaster
  • 3x rounds of scram
  • isMaster

I'd like to make it possible for the rsm to start fielding requests after the initial isMaster.

I can see a weakening of the ticket description to "should be running its isMaster calls as soon as possible, including on new un-authd connections if required". would that work for you? (probably by extending the current isMaster hook to update the rsm)

Comment by Andy Schwerin [ 18/Dec/18 ]

I'd like some clarity on why we want this. I've had it explained to me before, but I'd like to see it written down. Specifically, why should the replica set monitor run its ismaster calls on un-authed connections?

Generated at Thu Feb 08 04:49:40 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.