Re: Review Request 65268: SENTRY-1904: TransactionManager should limit the max time spent by transaction retry

2018-01-29 Thread Alexander Kolbasov

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/65268/#review196494
---




sentry-provider/sentry-provider-db/src/main/java/org/apache/sentry/provider/db/service/persistent/HMSFollower.java
Line 414 (original), 416 (patched)


This is unrelated change, please remove from the changeset.



sentry-provider/sentry-provider-db/src/main/java/org/apache/sentry/provider/db/service/persistent/TransactionManager.java
Line 231 (original), 236 (patched)


Do you need both?



sentry-provider/sentry-provider-db/src/main/java/org/apache/sentry/provider/db/service/persistent/TransactionManager.java
Line 242 (original)


It may still be useful to count number of retries and log it. I was often 
looking for broblems by looking at this log entry.



sentry-provider/sentry-provider-db/src/main/java/org/apache/sentry/provider/db/service/persistent/TransactionManager.java
Lines 249 (patched)


Do you need extra () here?



sentry-provider/sentry-provider-db/src/main/java/org/apache/sentry/provider/db/service/persistent/TransactionManager.java
Lines 250 (patched)


Why bvreak - you may adjust sleepTime to be smaller to fit within allotted 
time.



sentry-provider/sentry-provider-db/src/main/java/org/apache/sentry/provider/db/service/persistent/TransactionManager.java
Lines 261 (patched)


What if this condition is false? In this case you retry immediately without 
sleeping



sentry-provider/sentry-provider-db/src/main/java/org/apache/sentry/service/thrift/ServiceConstants.java
Lines 93 (patched)


The comment doesn't match the actual behavior - this is the initial sleep 
time.



sentry-provider/sentry-provider-db/src/main/java/org/apache/sentry/service/thrift/ServiceConstants.java
Lines 95 (patched)


The name is confusing. In is not a retry interval but an upper bound of 
execution for retries.



sentry-provider/sentry-provider-db/src/main/java/org/apache/sentry/service/thrift/ServiceConstants.java
Lines 96 (patched)


Please add time unit in the name.



sentry-provider/sentry-provider-db/src/main/java/org/apache/sentry/service/thrift/ServiceConstants.java
Lines 98 (patched)


Can you express this via Time units?



sentry-provider/sentry-provider-db/src/main/java/org/apache/sentry/service/thrift/ServiceConstants.java
Lines 102 (patched)


Please add time unit in the name.



sentry-provider/sentry-provider-db/src/main/java/org/apache/sentry/service/thrift/ServiceConstants.java
Lines 103 (patched)


How did you come up with 30 sec and 90 sec numbers?



sentry-provider/sentry-provider-db/src/test/java/org/apache/sentry/provider/db/service/persistent/TestSentryStore.java
Lines 2593 (patched)


Please add comment explaining what are you testing here. Looks like the 
name is not telling the truth - you are testing something complicated about 
notifications.

What you really need is a test that verifies that your failed transactions 
fail more or less within allotted time, but this test doesn't test for it.


- Alexander Kolbasov


On Jan. 29, 2018, 9:34 p.m., kalyan kumar kalvagadda wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/65268/
> ---
> 
> (Updated Jan. 29, 2018, 9:34 p.m.)
> 
> 
> Review request for sentry, Arjun Mishra, Na Li, Sergio Pena, and Vadim 
> Spector.
> 
> 
> Bugs: SENTRY-1904
> https://issues.apache.org/jira/browse/SENTRY-1904
> 
> 
> Repository: sentry
> 
> 
> Description
> ---
> 
> The TransactionManager uses exponential backoff strategy for transaction 
> retries. This may cause some transactions to be delayed by a very long time. 
> We should also have a constraint on the max time for a transaction so that we 
> do not retry for too long. 
> 
> New patch that is attached adds upper bounds on below
> 
> 1.Interval between the retry attempts which increases exponentially.
> 2.Total time a transaction could spend in retries.
>  
> 
> With out these limits we would not have a control on how long a transaction 
> could be be active.
> 
> 
> Diffs
> -
> 
>   

Re: Review Request 64955: SENTRY-2109: Fix the logic of identifying HMS out of Sync

2018-01-29 Thread kalyan kumar kalvagadda via Review Board

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/64955/
---

(Updated Jan. 30, 2018, 1:08 a.m.)


Review request for sentry, Alexander Kolbasov, Arjun Mishra, Na Li, Sergio 
Pena, and Vadim Spector.


Bugs: SENTRY-2109
https://issues.apache.org/jira/browse/SENTRY-2109


Repository: sentry


Description
---

This patch does couple of things
1. Avoid triggering full snapshots when gaps are observed while fetching new 
notifications. While fetching new notifications HMSFollower would would fetch 
notifications with last event-id as well. When it gets the notifications and if 
it doesn't get the notifications with event-id, full snpshot is triggered.
2. Functinalty to address gaps and out-of-sequence notificaitons by re-fetching 
addtional notifications that were already fetched. This solution is not fool 
proof. It does a best effort to reduse the chance of loosing notifications by 
re-fetching the notifications.This approach will introduce an over head of 
fetching addtional notifications that were already fetched. Overhead of DB 
look-up is addressed by using a cache. This reduces additional DB lookups 
needed to check if the notification was already processed.
2. Added looging to report duplicate events and out of order events for debug 
purpose.
3. Added new e2e tests to verfy this behavior.


Diffs (updated)
-

  
sentry-core/sentry-core-common/src/main/java/org/apache/sentry/core/common/exception/SentryOutOfSyncException.java
 PRE-CREATION 
  
sentry-provider/sentry-provider-db/src/main/java/org/apache/sentry/provider/db/service/persistent/HMSFollower.java
 2f2b98412e7dfdcc847ffe7975a70f452554e747 
  
sentry-provider/sentry-provider-db/src/main/java/org/apache/sentry/provider/db/service/persistent/SentryStore.java
 edea5b64d8f98c93aafc1fe43fa97e00c2ce2948 
  
sentry-provider/sentry-provider-db/src/main/java/org/apache/sentry/service/thrift/HiveNotificationFetcher.java
 93cc34f34c044dceb11d27e41ecbd1a14f64bed9 
  
sentry-provider/sentry-provider-db/src/main/java/org/apache/sentry/service/thrift/SentryService.java
 96c6810baa4d554db2b7d3739a28e3ff7e8b33a0 
  
sentry-provider/sentry-provider-db/src/main/java/org/apache/sentry/service/thrift/ServiceConstants.java
 7e02874b4be6a7109108809b1f404fe971b7b8e2 
  
sentry-provider/sentry-provider-db/src/test/java/org/apache/sentry/provider/db/service/persistent/TestHMSFollower.java
 79030780c35e5bda432e3ec3f01328e627cb50a6 
  
sentry-provider/sentry-provider-db/src/test/java/org/apache/sentry/provider/db/service/persistent/TestHMSFollowerSentryStoreIntegration.java
 91c90f9d302f4feb3a8b3d06541f43541c87bf0f 
  
sentry-provider/sentry-provider-db/src/test/java/org/apache/sentry/provider/db/service/persistent/TestSentryStore.java
 b4100278392986c161625a366212c6fef66ec0a9 
  
sentry-provider/sentry-provider-db/src/test/java/org/apache/sentry/service/thrift/TestHiveNotificationFetcher.java
 83a1becd46ac2d69c7d6dd05ed6253d1cdd8800d 
  
sentry-provider/sentry-provider-db/src/test/java/org/apache/sentry/service/thrift/TestHiveNotificationFetcherCache.java
 PRE-CREATION 
  
sentry-tests/sentry-tests-hive/src/test/java/org/apache/sentry/tests/e2e/dbprovider/TestSnapshotCreation.java
 PRE-CREATION 
  
sentry-tests/sentry-tests-hive/src/test/java/org/apache/sentry/tests/e2e/dbprovider/TestSnapshotCreationWithShorterHMSEventTtl.java
 PRE-CREATION 
  
sentry-tests/sentry-tests-hive/src/test/java/org/apache/sentry/tests/e2e/dbprovider/TestSnapshotWithLongerHMSFollowerLongerInterval.java
 PRE-CREATION 
  
sentry-tests/sentry-tests-hive/src/test/java/org/apache/sentry/tests/e2e/hdfs/TestHDFSIntegrationBase.java
 4cd00e6672730773c74b9840247d1f4d5f7bdfe4 


Diff: https://reviews.apache.org/r/64955/diff/7/

Changes: https://reviews.apache.org/r/64955/diff/6-7/


Testing
---

Made sure that tests pass.


Thanks,

kalyan kumar kalvagadda



Re: Review Request 64955: SENTRY-2109: Fix the logic of identifying HMS out of Sync

2018-01-29 Thread kalyan kumar kalvagadda via Review Board


> On Jan. 22, 2018, 8:27 p.m., Na Li wrote:
> > sentry-provider/sentry-provider-db/src/main/java/org/apache/sentry/service/thrift/HMSFollower.java
> > Lines 358 (patched)
> > 
> >
> > since we get max notification ID in next round, this event happens for 
> > every run. Can you change the logging level to debug instead of info?

That will not happen. Filter that we use in the NotificationFetcher would 
filter out those which are already processed.


> On Jan. 22, 2018, 8:27 p.m., Na Li wrote:
> > sentry-provider/sentry-provider-db/src/main/java/org/apache/sentry/service/thrift/HiveNotificationFetcher.java
> > Lines 231 (patched)
> > 
> >
> > does this happen for every received notification event? If so, each 
> > will cause a DB lookup. The overhead is high.
> > 
> > Since we know the max notification ID, we can only call 
> > sentryStore.isNotificationIdProcessed(id) if the id <= max notification ID.

This will happen only for out-of-order notification events. If there were no 
out-of-order notification events and gaps, the first notification would be the 
maxnotification processed by sentry.
I'm adding a seperate cache for Id's as well.


> On Jan. 22, 2018, 8:27 p.m., Na Li wrote:
> > sentry-provider/sentry-provider-db/src/main/java/org/apache/sentry/service/thrift/SentryService.java
> > Lines 644 (patched)
> > 
> >
> > do you need this function for testing?
> > 
> > SentryStore has this public function
> > /**
> >* @return ID of the path snapshot
> >*/
> >   public Gauge getLastPathsSnapshotIdGauge() {
> > return new Gauge() {
> >   @Override
> >   public Long getValue() {
> > try {
> >   return getCurrentAuthzPathsSnapshotID();
> > } catch (Exception e) {
> >   LOGGER.error("Can not read current paths snapshot ID", e);
> >   return NOTIFICATION_UNKNOWN;
> > }
> >   }
> > };
> >   }

I need API at sentry service level for testing puposes.


- kalyan kumar


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/64955/#review195928
---


On Jan. 30, 2018, 1:08 a.m., kalyan kumar kalvagadda wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/64955/
> ---
> 
> (Updated Jan. 30, 2018, 1:08 a.m.)
> 
> 
> Review request for sentry, Alexander Kolbasov, Arjun Mishra, Na Li, Sergio 
> Pena, and Vadim Spector.
> 
> 
> Bugs: SENTRY-2109
> https://issues.apache.org/jira/browse/SENTRY-2109
> 
> 
> Repository: sentry
> 
> 
> Description
> ---
> 
> This patch does couple of things
> 1. Avoid triggering full snapshots when gaps are observed while fetching new 
> notifications. While fetching new notifications HMSFollower would would fetch 
> notifications with last event-id as well. When it gets the notifications and 
> if it doesn't get the notifications with event-id, full snpshot is triggered.
> 2. Functinalty to address gaps and out-of-sequence notificaitons by 
> re-fetching addtional notifications that were already fetched. This solution 
> is not fool proof. It does a best effort to reduse the chance of loosing 
> notifications by re-fetching the notifications.This approach will introduce 
> an over head of fetching addtional notifications that were already fetched. 
> Overhead of DB look-up is addressed by using a cache. This reduces additional 
> DB lookups needed to check if the notification was already processed.
> 2. Added looging to report duplicate events and out of order events for debug 
> purpose.
> 3. Added new e2e tests to verfy this behavior.
> 
> 
> Diffs
> -
> 
>   
> sentry-core/sentry-core-common/src/main/java/org/apache/sentry/core/common/exception/SentryOutOfSyncException.java
>  PRE-CREATION 
>   
> sentry-provider/sentry-provider-db/src/main/java/org/apache/sentry/provider/db/service/persistent/HMSFollower.java
>  2f2b98412e7dfdcc847ffe7975a70f452554e747 
>   
> sentry-provider/sentry-provider-db/src/main/java/org/apache/sentry/provider/db/service/persistent/SentryStore.java
>  edea5b64d8f98c93aafc1fe43fa97e00c2ce2948 
>   
> sentry-provider/sentry-provider-db/src/main/java/org/apache/sentry/service/thrift/HiveNotificationFetcher.java
>  93cc34f34c044dceb11d27e41ecbd1a14f64bed9 
>   
> sentry-provider/sentry-provider-db/src/main/java/org/apache/sentry/service/thrift/SentryService.java
>  96c6810baa4d554db2b7d3739a28e3ff7e8b33a0 
>   
> 

Question about user-level privileges

2018-01-29 Thread Alexander Kolbasov
I am wondering what is the relationship between "users" as defined in
Sentry and users as defined in Unix or LDAP or Active Directory.

Should it be allowed to assign permissions to a user that doesn't exist?
Should there be any validation if users? Should these be treated together
or independently?

Also, there is discussion about adding permissions not to roles but to
users directly. How is it different from adding permissions not to roles
but to groups directly?

So far Sentry used role-based model - do we want to change it to
entity-based model?

- Alex


Re: Review Request 65268: SENTRY-1904: TransactionManager should limit the max time spent by transaction retry

2018-01-29 Thread kalyan kumar kalvagadda via Review Board

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/65268/
---

(Updated Jan. 29, 2018, 9:34 p.m.)


Review request for sentry, Arjun Mishra, Na Li, Sergio Pena, and Vadim Spector.


Changes
---

Addressed review comments.


Bugs: SENTRY-1904
https://issues.apache.org/jira/browse/SENTRY-1904


Repository: sentry


Description
---

The TransactionManager uses exponential backoff strategy for transaction 
retries. This may cause some transactions to be delayed by a very long time. We 
should also have a constraint on the max time for a transaction so that we do 
not retry for too long. 

New patch that is attached adds upper bounds on below

1.Interval between the retry attempts which increases exponentially.
2.Total time a transaction could spend in retries.
 

With out these limits we would not have a control on how long a transaction 
could be be active.


Diffs (updated)
-

  
sentry-provider/sentry-provider-db/src/main/java/org/apache/sentry/provider/db/service/persistent/HMSFollower.java
 2f2b984 
  
sentry-provider/sentry-provider-db/src/main/java/org/apache/sentry/provider/db/service/persistent/TransactionManager.java
 f4ff962 
  
sentry-provider/sentry-provider-db/src/main/java/org/apache/sentry/service/thrift/ServiceConstants.java
 7e02874 
  
sentry-provider/sentry-provider-db/src/test/java/org/apache/sentry/provider/db/service/persistent/TestHMSFollowerSentryStoreIntegration.java
 91c90f9 
  
sentry-provider/sentry-provider-db/src/test/java/org/apache/sentry/provider/db/service/persistent/TestSentryStore.java
 b410027 


Diff: https://reviews.apache.org/r/65268/diff/4/

Changes: https://reviews.apache.org/r/65268/diff/3-4/


Testing
---

Made sure all the tests pass.


Thanks,

kalyan kumar kalvagadda



Re: Review Request 64452: SENTRY-2091: User-based Privilege is broken by SENTRY-769

2018-01-29 Thread kalyan kumar kalvagadda via Review Board

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/64452/#review196465
---




sentry-binding/sentry-binding-hive-v2/src/main/java/org/apache/sentry/binding/hive/v2/HiveAuthzBindingHookBaseV2.java
Lines 812 (patched)


Should this be logged as an error? With this feature this is valid 
scenarion and need logged as an error.



sentry-provider/sentry-provider-common/src/main/java/org/apache/sentry/provider/common/ResourceAuthorizationProvider.java
Line 109 (original), 109 (patched)


Should this be logged as an error? With this feature this is valid 
scenarion and need logged as an error.


- kalyan kumar kalvagadda


On Jan. 22, 2018, 9:16 p.m., Na Li wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/64452/
> ---
> 
> (Updated Jan. 22, 2018, 9:16 p.m.)
> 
> 
> Review request for sentry, Arjun Mishra, kalyan kumar kalvagadda, Sergio 
> Pena, and Vadim Spector.
> 
> 
> Repository: sentry
> 
> 
> Description
> ---
> 
> Update the code to make sure user without group but with role has proper 
> access. 
> test case is added for the scenario that user has no group but with desired 
> role. 
> test case is added for the scenario that user has no group and no privilege 
> to allow the access
> 
> 
> Diffs
> -
> 
>   
> sentry-binding/sentry-binding-hive-v2/src/main/java/org/apache/sentry/binding/hive/v2/HiveAuthzBindingHookBaseV2.java
>  5a21dd3 
>   
> sentry-binding/sentry-binding-hive/src/main/java/org/apache/sentry/binding/hive/authz/HiveAuthzBindingHookBase.java
>  447deaf 
>   
> sentry-provider/sentry-provider-common/src/main/java/org/apache/sentry/provider/common/ResourceAuthorizationProvider.java
>  a9b98f3 
>   
> sentry-provider/sentry-provider-db/src/main/java/org/apache/sentry/provider/db/service/persistent/SentryStore.java
>  edea5b6 
>   
> sentry-tests/sentry-tests-hive/src/test/java/org/apache/sentry/tests/e2e/dbprovider/TestGrantUserToRole.java
>  5364937 
>   
> sentry-tests/sentry-tests-hive/src/test/java/org/apache/sentry/tests/e2e/hive/TestUserManagement.java
>  fd8ec56 
> 
> 
> Diff: https://reviews.apache.org/r/64452/diff/3/
> 
> 
> Testing
> ---
> 
> unit tests
> 
> 
> Thanks,
> 
> Na Li
> 
>



Re: Review Request 65268: SENTRY-1904: TransactionManager should limit the max time spent by transaction retry

2018-01-29 Thread Steve Moist via Review Board

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/65268/#review196463
---




sentry-provider/sentry-provider-db/src/main/java/org/apache/sentry/provider/db/service/persistent/TransactionManager.java
Lines 259 (patched)


If you're braking out of this anyway, why not just throw an Exception here 
instead of the break?



sentry-provider/sentry-provider-db/src/main/java/org/apache/sentry/service/thrift/ServiceConstants.java
Lines 102 (patched)


Change to 30_000 for readability or 30*1000



sentry-provider/sentry-provider-db/src/main/java/org/apache/sentry/service/thrift/ServiceConstants.java
Lines 108 (patched)


change to 300_000 or 5*60*1000


- Steve Moist


On Jan. 23, 2018, 11:40 p.m., kalyan kumar kalvagadda wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/65268/
> ---
> 
> (Updated Jan. 23, 2018, 11:40 p.m.)
> 
> 
> Review request for sentry, Arjun Mishra, Na Li, Sergio Pena, and Vadim 
> Spector.
> 
> 
> Bugs: SENTRY-1904
> https://issues.apache.org/jira/browse/SENTRY-1904
> 
> 
> Repository: sentry
> 
> 
> Description
> ---
> 
> The TransactionManager uses exponential backoff strategy for transaction 
> retries. This may cause some transactions to be delayed by a very long time. 
> We should also have a constraint on the max time for a transaction so that we 
> do not retry for too long. 
> 
> New patch that is attached adds upper bounds on below
> 
> 1.Interval between the retry attempts which increases exponentially.
> 2.Total time a transaction could spend in retries.
>  
> 
> With out these limits we would not have a control on how long a transaction 
> could be be active.
> 
> 
> Diffs
> -
> 
>   
> sentry-provider/sentry-provider-db/src/main/java/org/apache/sentry/provider/db/service/persistent/HMSFollower.java
>  2f2b98412e7dfdcc847ffe7975a70f452554e747 
>   
> sentry-provider/sentry-provider-db/src/main/java/org/apache/sentry/provider/db/service/persistent/SentryStore.java
>  edea5b64d8f98c93aafc1fe43fa97e00c2ce2948 
>   
> sentry-provider/sentry-provider-db/src/main/java/org/apache/sentry/provider/db/service/persistent/TransactionManager.java
>  f4ff962a67f8a5c23cc5c8daa7bcb861d2e6b6a5 
>   
> sentry-provider/sentry-provider-db/src/main/java/org/apache/sentry/service/thrift/ServiceConstants.java
>  7e02874b4be6a7109108809b1f404fe971b7b8e2 
>   
> sentry-provider/sentry-provider-db/src/test/java/org/apache/sentry/provider/db/service/persistent/TestSentryStore.java
>  b4100278392986c161625a366212c6fef66ec0a9 
> 
> 
> Diff: https://reviews.apache.org/r/65268/diff/3/
> 
> 
> Testing
> ---
> 
> Made sure all the tests pass.
> 
> 
> Thanks,
> 
> kalyan kumar kalvagadda
> 
>



Re: Review Request 65388: SENTRY-2124 LeaderStatusMonitor.toString() throws IllegalFormatConversionException with AtomicLong

2018-01-29 Thread kalyan kumar kalvagadda via Review Board

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/65388/#review196461
---


Ship it!




Ship It!

- kalyan kumar kalvagadda


On Jan. 29, 2018, 4:51 p.m., Xinran Tinney wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/65388/
> ---
> 
> (Updated Jan. 29, 2018, 4:51 p.m.)
> 
> 
> Review request for sentry, Alexander Kolbasov, Arjun Mishra, Colm O 
> hEigeartaigh, kalyan kumar kalvagadda, Na Li, and Sergio Pena.
> 
> 
> Repository: sentry
> 
> 
> Description
> ---
> 
> When I start Sentry, I noticed an exception on the console due to an illegal 
> format string in LeaderStatusMonitor.toString()
> java.util.IllegalFormatConversionException: d != 
> java.util.concurrent.atomic.AtomicLong 
> at java.util.Formatter$FormatSpecifier.failConversion(Formatter.java:4302) 
> at java.util.Formatter$FormatSpecifier.printInteger(Formatter.java:2793) 
> at java.util.Formatter$FormatSpecifier.print(Formatter.java:2747) 
> at java.util.Formatter.format(Formatter.java:2520) 
> at java.util.Formatter.format(Formatter.java:2455) 
> at java.lang.String.format(String.java:2940) 
> at 
> org.apache.sentry.provider.db.service.persistent.LeaderStatusMonitor.toString(LeaderStatusMonitor.java:282)
>  
> at 
> org.slf4j.helpers.MessageFormatter.safeObjectAppend(MessageFormatter.java:297)
>  
> at 
> org.slf4j.helpers.MessageFormatter.deeplyAppendParameter(MessageFormatter.java:269)
>  
> at org.slf4j.helpers.MessageFormatter.arrayFormat(MessageFormatter.java:227) 
> at org.slf4j.helpers.MessageFormatter.format(MessageFormatter.java:124) 
> at org.slf4j.impl.Log4jLoggerAdapter.info(Log4jLoggerAdapter.java:322) 
> at 
> org.apache.sentry.provider.db.service.persistent.LeaderStatusMonitor.takeLeadership(LeaderStatusMonitor.java:251)
>  
> at 
> sentry.org.apache.curator.framework.recipes.leader.LeaderSelector$WrappedListener.takeLeadership(LeaderSelector.java:537)
>  
> at 
> sentry.org.apache.curator.framework.recipes.leader.LeaderSelector.doWork(LeaderSelector.java:399)
>  
> at 
> sentry.org.apache.curator.framework.recipes.leader.LeaderSelector.doWorkLoop(LeaderSelector.java:444)
>  
> at 
> sentry.org.apache.curator.framework.recipes.leader.LeaderSelector.access$100(LeaderSelector.java:64)
>  
> at 
> sentry.org.apache.curator.framework.recipes.leader.LeaderSelector$2.call(LeaderSelector.java:245)
>  
> at 
> sentry.org.apache.curator.framework.recipes.leader.LeaderSelector$2.call(LeaderSelector.java:239)
>  
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>  
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> 
> 
> Diffs
> -
> 
>   
> sentry-provider/sentry-provider-db/src/main/java/org/apache/sentry/provider/db/service/persistent/LeaderStatusMonitor.java
>  25a70bda 
> 
> 
> Diff: https://reviews.apache.org/r/65388/diff/1/
> 
> 
> Testing
> ---
> 
> mvn clean install
> 
> 
> Thanks,
> 
> Xinran Tinney
> 
>



Re: Review Request 65388: SENTRY-2124 LeaderStatusMonitor.toString() throws IllegalFormatConversionException with AtomicLong

2018-01-29 Thread Steve Moist via Review Board

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/65388/#review196460
---


Ship it!




Ship It!

- Steve Moist


On Jan. 29, 2018, 4:51 p.m., Xinran Tinney wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/65388/
> ---
> 
> (Updated Jan. 29, 2018, 4:51 p.m.)
> 
> 
> Review request for sentry, Alexander Kolbasov, Arjun Mishra, Colm O 
> hEigeartaigh, kalyan kumar kalvagadda, Na Li, and Sergio Pena.
> 
> 
> Repository: sentry
> 
> 
> Description
> ---
> 
> When I start Sentry, I noticed an exception on the console due to an illegal 
> format string in LeaderStatusMonitor.toString()
> java.util.IllegalFormatConversionException: d != 
> java.util.concurrent.atomic.AtomicLong 
> at java.util.Formatter$FormatSpecifier.failConversion(Formatter.java:4302) 
> at java.util.Formatter$FormatSpecifier.printInteger(Formatter.java:2793) 
> at java.util.Formatter$FormatSpecifier.print(Formatter.java:2747) 
> at java.util.Formatter.format(Formatter.java:2520) 
> at java.util.Formatter.format(Formatter.java:2455) 
> at java.lang.String.format(String.java:2940) 
> at 
> org.apache.sentry.provider.db.service.persistent.LeaderStatusMonitor.toString(LeaderStatusMonitor.java:282)
>  
> at 
> org.slf4j.helpers.MessageFormatter.safeObjectAppend(MessageFormatter.java:297)
>  
> at 
> org.slf4j.helpers.MessageFormatter.deeplyAppendParameter(MessageFormatter.java:269)
>  
> at org.slf4j.helpers.MessageFormatter.arrayFormat(MessageFormatter.java:227) 
> at org.slf4j.helpers.MessageFormatter.format(MessageFormatter.java:124) 
> at org.slf4j.impl.Log4jLoggerAdapter.info(Log4jLoggerAdapter.java:322) 
> at 
> org.apache.sentry.provider.db.service.persistent.LeaderStatusMonitor.takeLeadership(LeaderStatusMonitor.java:251)
>  
> at 
> sentry.org.apache.curator.framework.recipes.leader.LeaderSelector$WrappedListener.takeLeadership(LeaderSelector.java:537)
>  
> at 
> sentry.org.apache.curator.framework.recipes.leader.LeaderSelector.doWork(LeaderSelector.java:399)
>  
> at 
> sentry.org.apache.curator.framework.recipes.leader.LeaderSelector.doWorkLoop(LeaderSelector.java:444)
>  
> at 
> sentry.org.apache.curator.framework.recipes.leader.LeaderSelector.access$100(LeaderSelector.java:64)
>  
> at 
> sentry.org.apache.curator.framework.recipes.leader.LeaderSelector$2.call(LeaderSelector.java:245)
>  
> at 
> sentry.org.apache.curator.framework.recipes.leader.LeaderSelector$2.call(LeaderSelector.java:239)
>  
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>  
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> 
> 
> Diffs
> -
> 
>   
> sentry-provider/sentry-provider-db/src/main/java/org/apache/sentry/provider/db/service/persistent/LeaderStatusMonitor.java
>  25a70bda 
> 
> 
> Diff: https://reviews.apache.org/r/65388/diff/1/
> 
> 
> Testing
> ---
> 
> mvn clean install
> 
> 
> Thanks,
> 
> Xinran Tinney
> 
>



Re: permission request to edit sentry web page

2018-01-29 Thread Na Li
Colm,

Thanks,

Lina

On Sat, Jan 27, 2018 at 10:37 AM, Colm O hEigeartaigh 
wrote:

> You should be good now - make sure to log off first + then log on again.
>
> Colm.
>
> On Fri, Jan 26, 2018 at 5:47 PM, Na Li  wrote:
>
> > Colm,
> >
> > My cwiki username is "linaataustin".
> >
> > Thanks,
> >
> > Lina
> >
> > On Fri, Jan 26, 2018 at 11:22 AM, Kalyan Kumar Kalvagadda <
> > kkal...@cloudera.com> wrote:
> >
> > > Lina,
> > >
> > > If you are planning to add new jira's to the roadmap wiki page. You
> don't
> > > have to make changes to wiki page. You just to add label "roadmap" to
> the
> > > new jira's.
> > > Th widget in the page will pull it.
> > >
> > > -Kalyan
> > >
> > > -Kalyan
> > >
> > > On Fri, Jan 26, 2018 at 10:47 AM, Colm O hEigeartaigh <
> > cohei...@apache.org
> > > >
> > > wrote:
> > >
> > > > Hi Lina,
> > > >
> > > > What's your cwiki username?
> > > >
> > > > Colm.
> > > >
> > > > On Fri, Jan 26, 2018 at 4:23 PM, Na Li  wrote:
> > > >
> > > > > Hello,
> > > > >
> > > > > Can I have permission to edit the following page for sentry?
> > > > >
> > > > > https://cwiki.apache.org/confluence/display/SENTRY/
> > > > > Sentry+Roadmap+and+ideas
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Lina
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Colm O hEigeartaigh
> > > >
> > > > Talend Community Coder
> > > > http://coders.talend.com
> > > >
> > >
> >
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>


Re: Review Request 65388: SENTRY-2124 LeaderStatusMonitor.toString() throws IllegalFormatConversionException with AtomicLong

2018-01-29 Thread Arjun Mishra via Review Board

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/65388/#review196439
---


Ship it!




- Arjun Mishra


On Jan. 29, 2018, 4:51 p.m., Xinran Tinney wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/65388/
> ---
> 
> (Updated Jan. 29, 2018, 4:51 p.m.)
> 
> 
> Review request for sentry, Alexander Kolbasov, Arjun Mishra, Colm O 
> hEigeartaigh, kalyan kumar kalvagadda, Na Li, and Sergio Pena.
> 
> 
> Repository: sentry
> 
> 
> Description
> ---
> 
> When I start Sentry, I noticed an exception on the console due to an illegal 
> format string in LeaderStatusMonitor.toString()
> java.util.IllegalFormatConversionException: d != 
> java.util.concurrent.atomic.AtomicLong 
> at java.util.Formatter$FormatSpecifier.failConversion(Formatter.java:4302) 
> at java.util.Formatter$FormatSpecifier.printInteger(Formatter.java:2793) 
> at java.util.Formatter$FormatSpecifier.print(Formatter.java:2747) 
> at java.util.Formatter.format(Formatter.java:2520) 
> at java.util.Formatter.format(Formatter.java:2455) 
> at java.lang.String.format(String.java:2940) 
> at 
> org.apache.sentry.provider.db.service.persistent.LeaderStatusMonitor.toString(LeaderStatusMonitor.java:282)
>  
> at 
> org.slf4j.helpers.MessageFormatter.safeObjectAppend(MessageFormatter.java:297)
>  
> at 
> org.slf4j.helpers.MessageFormatter.deeplyAppendParameter(MessageFormatter.java:269)
>  
> at org.slf4j.helpers.MessageFormatter.arrayFormat(MessageFormatter.java:227) 
> at org.slf4j.helpers.MessageFormatter.format(MessageFormatter.java:124) 
> at org.slf4j.impl.Log4jLoggerAdapter.info(Log4jLoggerAdapter.java:322) 
> at 
> org.apache.sentry.provider.db.service.persistent.LeaderStatusMonitor.takeLeadership(LeaderStatusMonitor.java:251)
>  
> at 
> sentry.org.apache.curator.framework.recipes.leader.LeaderSelector$WrappedListener.takeLeadership(LeaderSelector.java:537)
>  
> at 
> sentry.org.apache.curator.framework.recipes.leader.LeaderSelector.doWork(LeaderSelector.java:399)
>  
> at 
> sentry.org.apache.curator.framework.recipes.leader.LeaderSelector.doWorkLoop(LeaderSelector.java:444)
>  
> at 
> sentry.org.apache.curator.framework.recipes.leader.LeaderSelector.access$100(LeaderSelector.java:64)
>  
> at 
> sentry.org.apache.curator.framework.recipes.leader.LeaderSelector$2.call(LeaderSelector.java:245)
>  
> at 
> sentry.org.apache.curator.framework.recipes.leader.LeaderSelector$2.call(LeaderSelector.java:239)
>  
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>  
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> 
> 
> Diffs
> -
> 
>   
> sentry-provider/sentry-provider-db/src/main/java/org/apache/sentry/provider/db/service/persistent/LeaderStatusMonitor.java
>  25a70bda 
> 
> 
> Diff: https://reviews.apache.org/r/65388/diff/1/
> 
> 
> Testing
> ---
> 
> mvn clean install
> 
> 
> Thanks,
> 
> Xinran Tinney
> 
>



Re: Review Request 65388: SENTRY-2124 LeaderStatusMonitor.toString() throws IllegalFormatConversionException with AtomicLong

2018-01-29 Thread Sergio Pena via Review Board

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/65388/#review196438
---


Ship it!




Ship It!

- Sergio Pena


On Jan. 29, 2018, 4:51 p.m., Xinran Tinney wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/65388/
> ---
> 
> (Updated Jan. 29, 2018, 4:51 p.m.)
> 
> 
> Review request for sentry, Alexander Kolbasov, Arjun Mishra, Colm O 
> hEigeartaigh, kalyan kumar kalvagadda, Na Li, and Sergio Pena.
> 
> 
> Repository: sentry
> 
> 
> Description
> ---
> 
> When I start Sentry, I noticed an exception on the console due to an illegal 
> format string in LeaderStatusMonitor.toString()
> java.util.IllegalFormatConversionException: d != 
> java.util.concurrent.atomic.AtomicLong 
> at java.util.Formatter$FormatSpecifier.failConversion(Formatter.java:4302) 
> at java.util.Formatter$FormatSpecifier.printInteger(Formatter.java:2793) 
> at java.util.Formatter$FormatSpecifier.print(Formatter.java:2747) 
> at java.util.Formatter.format(Formatter.java:2520) 
> at java.util.Formatter.format(Formatter.java:2455) 
> at java.lang.String.format(String.java:2940) 
> at 
> org.apache.sentry.provider.db.service.persistent.LeaderStatusMonitor.toString(LeaderStatusMonitor.java:282)
>  
> at 
> org.slf4j.helpers.MessageFormatter.safeObjectAppend(MessageFormatter.java:297)
>  
> at 
> org.slf4j.helpers.MessageFormatter.deeplyAppendParameter(MessageFormatter.java:269)
>  
> at org.slf4j.helpers.MessageFormatter.arrayFormat(MessageFormatter.java:227) 
> at org.slf4j.helpers.MessageFormatter.format(MessageFormatter.java:124) 
> at org.slf4j.impl.Log4jLoggerAdapter.info(Log4jLoggerAdapter.java:322) 
> at 
> org.apache.sentry.provider.db.service.persistent.LeaderStatusMonitor.takeLeadership(LeaderStatusMonitor.java:251)
>  
> at 
> sentry.org.apache.curator.framework.recipes.leader.LeaderSelector$WrappedListener.takeLeadership(LeaderSelector.java:537)
>  
> at 
> sentry.org.apache.curator.framework.recipes.leader.LeaderSelector.doWork(LeaderSelector.java:399)
>  
> at 
> sentry.org.apache.curator.framework.recipes.leader.LeaderSelector.doWorkLoop(LeaderSelector.java:444)
>  
> at 
> sentry.org.apache.curator.framework.recipes.leader.LeaderSelector.access$100(LeaderSelector.java:64)
>  
> at 
> sentry.org.apache.curator.framework.recipes.leader.LeaderSelector$2.call(LeaderSelector.java:245)
>  
> at 
> sentry.org.apache.curator.framework.recipes.leader.LeaderSelector$2.call(LeaderSelector.java:239)
>  
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>  
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> 
> 
> Diffs
> -
> 
>   
> sentry-provider/sentry-provider-db/src/main/java/org/apache/sentry/provider/db/service/persistent/LeaderStatusMonitor.java
>  25a70bda 
> 
> 
> Diff: https://reviews.apache.org/r/65388/diff/1/
> 
> 
> Testing
> ---
> 
> mvn clean install
> 
> 
> Thanks,
> 
> Xinran Tinney
> 
>



Re: Review Request 64452: SENTRY-2091: User-based Privilege is broken by SENTRY-769

2018-01-29 Thread Sergio Pena via Review Board

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/64452/#review196435
---




sentry-binding/sentry-binding-hive-v2/src/main/java/org/apache/sentry/binding/hive/v2/HiveAuthzBindingHookBaseV2.java
Lines 805-814 (patched)


This class is not used anymore and will be removed in the future, I don't 
think we should continue maintaining it.



sentry-binding/sentry-binding-hive/src/main/java/org/apache/sentry/binding/hive/authz/HiveAuthzBindingHookBase.java
Line 550 (original)


All the HiveAuthzBindingHookBase changes are not related to the fix of this 
issue. Can we remove those changes to keep patch smaller and the history clean? 
I think We should fix those issues on other patches that address syntax issues.



sentry-provider/sentry-provider-common/src/main/java/org/apache/sentry/provider/common/ResourceAuthorizationProvider.java
Lines 107-109 (original), 107-109 (patched)


What's the reason of chaning to newHashSet() instead of leaving the 
emptySet()? Both will have empty sets, don't they?

Also, is it necessary to change the variable name 'e' to 'ex'?



sentry-tests/sentry-tests-hive/src/test/java/org/apache/sentry/tests/e2e/dbprovider/TestGrantUserToRole.java
Lines 188 (patched)


This could have a tabl or empty space, Please remove this change.



sentry-tests/sentry-tests-hive/src/test/java/org/apache/sentry/tests/e2e/dbprovider/TestGrantUserToRole.java
Lines 288-291 (patched)


Can this test be moved to the previous test? I think both tests are similar.



sentry-tests/sentry-tests-hive/src/test/java/org/apache/sentry/tests/e2e/hive/TestUserManagement.java
Line 369 (original), 369 (patched)


Why do we need the table name change? Was the older name causing problems?



sentry-tests/sentry-tests-hive/src/test/java/org/apache/sentry/tests/e2e/hive/TestUserManagement.java
Lines 371 (patched)


This could have a tabl or empty space, Please remove this change.


- Sergio Pena


On Jan. 22, 2018, 9:16 p.m., Na Li wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/64452/
> ---
> 
> (Updated Jan. 22, 2018, 9:16 p.m.)
> 
> 
> Review request for sentry, Arjun Mishra, kalyan kumar kalvagadda, Sergio 
> Pena, and Vadim Spector.
> 
> 
> Repository: sentry
> 
> 
> Description
> ---
> 
> Update the code to make sure user without group but with role has proper 
> access. 
> test case is added for the scenario that user has no group but with desired 
> role. 
> test case is added for the scenario that user has no group and no privilege 
> to allow the access
> 
> 
> Diffs
> -
> 
>   
> sentry-binding/sentry-binding-hive-v2/src/main/java/org/apache/sentry/binding/hive/v2/HiveAuthzBindingHookBaseV2.java
>  5a21dd3 
>   
> sentry-binding/sentry-binding-hive/src/main/java/org/apache/sentry/binding/hive/authz/HiveAuthzBindingHookBase.java
>  447deaf 
>   
> sentry-provider/sentry-provider-common/src/main/java/org/apache/sentry/provider/common/ResourceAuthorizationProvider.java
>  a9b98f3 
>   
> sentry-provider/sentry-provider-db/src/main/java/org/apache/sentry/provider/db/service/persistent/SentryStore.java
>  edea5b6 
>   
> sentry-tests/sentry-tests-hive/src/test/java/org/apache/sentry/tests/e2e/dbprovider/TestGrantUserToRole.java
>  5364937 
>   
> sentry-tests/sentry-tests-hive/src/test/java/org/apache/sentry/tests/e2e/hive/TestUserManagement.java
>  fd8ec56 
> 
> 
> Diff: https://reviews.apache.org/r/64452/diff/3/
> 
> 
> Testing
> ---
> 
> unit tests
> 
> 
> Thanks,
> 
> Na Li
> 
>



Review Request 65388: SENTRY-2124 LeaderStatusMonitor.toString() throws IllegalFormatConversionException with AtomicLong

2018-01-29 Thread Xinran Tinney

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/65388/
---

Review request for sentry, Alexander Kolbasov, Arjun Mishra, Colm O 
hEigeartaigh, kalyan kumar kalvagadda, Na Li, and Sergio Pena.


Repository: sentry


Description
---

When I start Sentry, I noticed an exception on the console due to an illegal 
format string in LeaderStatusMonitor.toString()
java.util.IllegalFormatConversionException: d != 
java.util.concurrent.atomic.AtomicLong 
at java.util.Formatter$FormatSpecifier.failConversion(Formatter.java:4302) 
at java.util.Formatter$FormatSpecifier.printInteger(Formatter.java:2793) 
at java.util.Formatter$FormatSpecifier.print(Formatter.java:2747) 
at java.util.Formatter.format(Formatter.java:2520) 
at java.util.Formatter.format(Formatter.java:2455) 
at java.lang.String.format(String.java:2940) 
at 
org.apache.sentry.provider.db.service.persistent.LeaderStatusMonitor.toString(LeaderStatusMonitor.java:282)
 
at 
org.slf4j.helpers.MessageFormatter.safeObjectAppend(MessageFormatter.java:297) 
at 
org.slf4j.helpers.MessageFormatter.deeplyAppendParameter(MessageFormatter.java:269)
 
at org.slf4j.helpers.MessageFormatter.arrayFormat(MessageFormatter.java:227) 
at org.slf4j.helpers.MessageFormatter.format(MessageFormatter.java:124) 
at org.slf4j.impl.Log4jLoggerAdapter.info(Log4jLoggerAdapter.java:322) 
at 
org.apache.sentry.provider.db.service.persistent.LeaderStatusMonitor.takeLeadership(LeaderStatusMonitor.java:251)
 
at 
sentry.org.apache.curator.framework.recipes.leader.LeaderSelector$WrappedListener.takeLeadership(LeaderSelector.java:537)
 
at 
sentry.org.apache.curator.framework.recipes.leader.LeaderSelector.doWork(LeaderSelector.java:399)
 
at 
sentry.org.apache.curator.framework.recipes.leader.LeaderSelector.doWorkLoop(LeaderSelector.java:444)
 
at 
sentry.org.apache.curator.framework.recipes.leader.LeaderSelector.access$100(LeaderSelector.java:64)
 
at 
sentry.org.apache.curator.framework.recipes.leader.LeaderSelector$2.call(LeaderSelector.java:245)
 
at 
sentry.org.apache.curator.framework.recipes.leader.LeaderSelector$2.call(LeaderSelector.java:239)
 
at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)


Diffs
-

  
sentry-provider/sentry-provider-db/src/main/java/org/apache/sentry/provider/db/service/persistent/LeaderStatusMonitor.java
 25a70bda 


Diff: https://reviews.apache.org/r/65388/diff/1/


Testing
---

mvn clean install


Thanks,

Xinran Tinney



Re: Review Request 64955: SENTRY-2109: Fix the logic of identifying HMS out of Sync

2018-01-29 Thread kalyan kumar kalvagadda via Review Board

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/64955/
---

(Updated Jan. 29, 2018, 3:47 p.m.)


Review request for sentry, Alexander Kolbasov, Arjun Mishra, Na Li, Sergio 
Pena, and Vadim Spector.


Changes
---

Added more tests to verify the cache and addressed review comments.


Bugs: SENTRY-2109
https://issues.apache.org/jira/browse/SENTRY-2109


Repository: sentry


Description
---

This patch does couple of things
1. Avoid triggering full snapshots when gaps are observed while fetching new 
notifications. While fetching new notifications HMSFollower would would fetch 
notifications with last event-id as well. When it gets the notifications and if 
it doesn't get the notifications with event-id, full snpshot is triggered.
2. Functinalty to address gaps and out-of-sequence notificaitons by re-fetching 
addtional notifications that were already fetched. This solution is not fool 
proof. It does a best effort to reduse the chance of loosing notifications by 
re-fetching the notifications.This approach will introduce an over head of 
fetching addtional notifications that were already fetched. Overhead of DB 
look-up is addressed by using a cache. This reduces additional DB lookups 
needed to check if the notification was already processed.
2. Added looging to report duplicate events and out of order events for debug 
purpose.
3. Added new e2e tests to verfy this behavior.


Diffs (updated)
-

  
sentry-core/sentry-core-common/src/main/java/org/apache/sentry/core/common/exception/SentryOutOfSyncException.java
 PRE-CREATION 
  
sentry-provider/sentry-provider-db/src/main/java/org/apache/sentry/provider/db/service/persistent/HMSFollower.java
 2f2b984 
  
sentry-provider/sentry-provider-db/src/main/java/org/apache/sentry/provider/db/service/persistent/SentryStore.java
 edea5b6 
  
sentry-provider/sentry-provider-db/src/main/java/org/apache/sentry/service/thrift/HiveNotificationFetcher.java
 93cc34f 
  
sentry-provider/sentry-provider-db/src/main/java/org/apache/sentry/service/thrift/SentryService.java
 96c6810 
  
sentry-provider/sentry-provider-db/src/main/java/org/apache/sentry/service/thrift/ServiceConstants.java
 7e02874 
  
sentry-provider/sentry-provider-db/src/test/java/org/apache/sentry/provider/db/service/persistent/TestHMSFollower.java
 7903078 
  
sentry-provider/sentry-provider-db/src/test/java/org/apache/sentry/provider/db/service/persistent/TestHMSFollowerSentryStoreIntegration.java
 91c90f9 
  
sentry-provider/sentry-provider-db/src/test/java/org/apache/sentry/provider/db/service/persistent/TestSentryStore.java
 b410027 
  
sentry-provider/sentry-provider-db/src/test/java/org/apache/sentry/service/thrift/TestHiveNotificationFetcher.java
 83a1bec 
  
sentry-provider/sentry-provider-db/src/test/java/org/apache/sentry/service/thrift/TestHiveNotificationFetcherCache.java
 PRE-CREATION 
  
sentry-tests/sentry-tests-hive/src/test/java/org/apache/sentry/tests/e2e/dbprovider/TestSnapshotCreation.java
 PRE-CREATION 
  
sentry-tests/sentry-tests-hive/src/test/java/org/apache/sentry/tests/e2e/dbprovider/TestSnapshotCreationWithShorterHMSEventTtl.java
 PRE-CREATION 
  
sentry-tests/sentry-tests-hive/src/test/java/org/apache/sentry/tests/e2e/dbprovider/TestSnapshotWithLongerHMSFollowerLongerInterval.java
 PRE-CREATION 
  
sentry-tests/sentry-tests-hive/src/test/java/org/apache/sentry/tests/e2e/hdfs/TestHDFSIntegrationBase.java
 4cd00e6 


Diff: https://reviews.apache.org/r/64955/diff/6/

Changes: https://reviews.apache.org/r/64955/diff/5-6/


Testing
---

Made sure that tests pass.


Thanks,

kalyan kumar kalvagadda