[
https://issues.apache.org/jira/browse/SENTRY-1800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16047242#comment-16047242
]
Alexander Kolbasov commented on SENTRY-1800:
--------------------------------------------
[~lina.li] No, SENTRY-1792 just ensures that all entries are properly sorted.
We didn't see any specific issues without it, but it wasn't clear whether this
is always the case. SENTRY-1795 changed the way to handle IDs from
auto-increment to manual and introduced the test that started to fail, so this
issue addresses fixing the test. The problem is that sometimes even after all
the retries, the new ID can't be stored so it is possible that the result may
have fewer entries then expected. The fix drops the check for the size of the
result and only verifies that there are no holes. It is possible that some
updates never make it.
> Flaky testConcurrentUpdateChanges test
> --------------------------------------
>
> Key: SENTRY-1800
> URL: https://issues.apache.org/jira/browse/SENTRY-1800
> Project: Sentry
> Issue Type: Sub-task
> Components: Sentry
> Affects Versions: sentry-ha-redesign
> Reporter: Alexander Kolbasov
> Assignee: Alexander Kolbasov
> Labels: sentry-ha
> Fix For: sentry-ha-redesign
>
> Attachments: SENTRY-1800.01-sentry-ha-redesign.patch
>
>
> 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.4.14#64029)
