Adar Dembo has posted comments on this change. Change subject: KUDU-2124. Don't hold session lock while initializing a TabletCopySession ......................................................................
Patch Set 2: > It's possible because the remote can time out and retry based on > the leader telling it to retry, and those requests can be stuck in > the server's RPC queue. See KUDU-1436 for an early example of this. Hmm, and we don't want to pay the cost of instantiating any sessions beyond the first one? Okay, I guess I can buy that. I was asking because if we didn't mind creating the occasional extra session or two (and just let them get cleaned up via "expiration"), we could use an incrementing integer as the session key, which would guarantee no session reuse at all, thus avoiding the thorny synchronization around session creation. What do you think about using a per-session std::once to guarantee Init is called? The synchronization would be something like this: Take lock. Look for existing entry in session map. If not there, create a new session and it to the map. Release lock. Create a ScopedCleanup that removes the session with the lock held. RETURN_NOT_OK(Init) // via session->once, so it's a no-op if the session is already initted cleanup.cancel() This way we don't have to worry about lock interaction: the session lock and the once's spinlock are independent. -- To view, visit http://gerrit.cloudera.org:8080/7919 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings Gerrit-MessageType: comment Gerrit-Change-Id: I05f5b3c6a012067c95bb54f040bee2bb19388bfe Gerrit-PatchSet: 2 Gerrit-Project: kudu Gerrit-Branch: master Gerrit-Owner: Mike Percy <mpe...@apache.org> Gerrit-Reviewer: Adar Dembo <a...@cloudera.com> Gerrit-Reviewer: Dan Burkert <danburk...@apache.org> Gerrit-Reviewer: Kudu Jenkins Gerrit-Reviewer: Mike Percy <mpe...@apache.org> Gerrit-Reviewer: Tidy Bot Gerrit-HasComments: No
