Adar Dembo has posted comments on this change. Change subject: KUDU-1473: fix some tablet lock usage in CatalogManager ......................................................................
Patch Set 2: (1 comment) http://gerrit.cloudera.org:8080/#/c/3309/2//COMMIT_MSG Commit Message: Line 15: GetTableLocations() call to a table whose tablets have been assigned but are > I'm not entirely following what GetTableLocations has to do with this bug - Yes, the crash is in ProcessPendingAssignments, but the DCHECK itself is: DCHECK(lock_.HasReaders() || lock_.HasWriteLock()); So we accessed an object without a lock while someone else had that object locked for reading or for writing. I don't think that "someone else" is the background thread, so I think it's got to be another client thread. A GetTableLocations() or GetTabletLocations() on the same table would lock some tablets for reading, and since the Java code in question does exactly that (create a table followed by two calls to GetTabletLocations() on the same table), it's conceivable that it's responsible. It's strange, though, since the Java client is supposed to wait for the table to be created before continuing. That's why I'm going to spend some more time digging into this. -- To view, visit http://gerrit.cloudera.org:8080/3309 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings Gerrit-MessageType: comment Gerrit-Change-Id: I8e24f6035f4d778995ea3f295396f5fbd760d6c6 Gerrit-PatchSet: 2 Gerrit-Project: kudu Gerrit-Branch: master Gerrit-Owner: Adar Dembo <a...@cloudera.com> Gerrit-Reviewer: Adar Dembo <a...@cloudera.com> Gerrit-Reviewer: Kudu Jenkins Gerrit-Reviewer: Todd Lipcon <t...@apache.org> Gerrit-HasComments: Yes
