[jira] [Created] (SENTRY-1800) Updates can still have holes

["Alexander Kolbasov (JIRA)" <ji...@apache.org>]

Alexander Kolbasov created SENTRY-1800:
------------------------------------------

             Summary: Updates can still have holes
                 Key: SENTRY-1800
                 URL: https://issues.apache.org/jira/browse/SENTRY-1800
             Project: Sentry
          Issue Type: Sub-task
          Components: Sentry
            Reporter: Alexander Kolbasov
            Assignee: Lei (Eddy) Xu


The fixed for SENTRY-1795 was supposed to guarantee that we don't have any holes in the update tables.

The ffix includes the new test {{TestSentryStore#testDuplicateNotification}}. This test passes sometimes but sometimes fails, for example:

{code}
java.lang.AssertionError: 
Expected :5000
Actual   :4863
 <Click to see difference>


	at org.junit.Assert.fail(Assert.java:93)
	at org.junit.Assert.failNotEquals(Assert.java:647)
	at org.junit.Assert.assertEquals(Assert.java:128)
	at org.junit.Assert.assertEquals(Assert.java:472)
	at org.junit.Assert.assertEquals(Assert.java:456)
	at org.apache.sentry.provider.db.service.persistent.TestSentryStore.testConcurrentUpdateChanges(TestSentryStore.java:2977)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
	at org.junit.internal.runners.statements.FailOnTimeout$StatementThread.run(FailOnTimeout.java:62)
{code}

It fails here:

{code}
    List<MSentryPermChange> changes = sentryStore.getMSentryPermChanges();
    assertEquals(numThreads * numChangesPerThread, changes.size());
{code}

meaning that some changes are missing. The question is whether they are missing with holes or we just have a shorter list?




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)