[
https://issues.apache.org/jira/browse/KUDU-2842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16932940#comment-16932940
]
Adar Dembo commented on KUDU-2842:
----------------------------------
Yeah either of those should work. The former will lead to more contention
between lookups and operations that commit tablet changes (e.g. processing
tablet reports), while the latter will increase the computational and memory
footprint of a lookup. We can use the benchmark committed in KUDU-2711 as a
guide.
> Data race in CatalogManager::GetTableLocations
> ----------------------------------------------
>
> Key: KUDU-2842
> URL: https://issues.apache.org/jira/browse/KUDU-2842
> Project: Kudu
> Issue Type: Bug
> Components: master
> Affects Versions: 1.10.0
> Reporter: Adar Dembo
> Priority: Blocker
> Attachments: test.txt
>
>
> Saw this on a test run.
> I think the problem is that TSInfosDict is reused for all calls to
> BuildLocationsForTablet for a particular table, and the map inside it points
> to peer UUIDs by reference (i.e. StringPiece) instead of by copy. Thus, when
> a given BuildLocationsForTablet call completes, the tablet lock is released
> and the catalog manager is free to destroy that tablet's TabletInfo (i.e. via
> committing a mutation in ProcessTabletReport). But the very next call to
> BuildLocationsForTablet may cause TSInfosDict map keys to be read and
> compared, even though the memory backing those keys no longer exists.
> Assigning to Will because he committed 586e957f7 but cc'ing [~tlipcon] as he
> was the original author of the code.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
