Hi Lei, > On Jun 7, 2017, at 11:34 PM, Lei Xu <[email protected]> wrote: > > Hi, Sasha > > It is still problematic due to the max(change ID) scanning. > > One possible way to address it is that, in HMSFollower#run(), it ask > sentryStore to cache max change IDs of these two tables with in > sentryStore itself. > So that each time, when HMSFollower wake up, it refresh sentryStore's > cached change ID value. And since DB write is fenced, so the cached > change IDs should be valid during the execution ?
The fencing is a best-effort - it isn’t guaranteed to always fence. There may be some delay between the time a new leader is elected and the old leader stops processing notifications. > > Do you know whether SentryPolicyStoreProcessor is also fenced by > leaderMonitor? SentryPolicyStoreProcessor also has a write path to > the DB via SentryStore. No, it isn’t fenced at all. Only HMSFollower is. - Alex > > On Wed, Jun 7, 2017 at 10:05 PM, Alexander Kolbasov <[email protected]> > wrote: >> Lei, >> >> Thank you for fixing SENTRY-1795. I remember we had some issues earlier with >> this approach - see some discussion in SENTRY-1706 where you encountered a >> deadlock issue. >> >> Do you think that this is still a problem or not? >> >> - Sasha > > > > -- > Lei (Eddy) Xu > Software Engineer, Cloudera
