[
https://issues.apache.org/jira/browse/SENTRY-2106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16305572#comment-16305572
]
kalyan kumar kalvagadda commented on SENTRY-2106:
-------------------------------------------------
[~arjunmishra13] I have couple of comments on the approach taken. Before going
into that, I would re-iterate couple of assumptions that HMSFollower has taken
# Method getCurrentNotificationEventId on Hmsclient would always return the
last issued notification event id, which HMSFollower assumes to be the biggest.
Which doesn't seems to be true. We don't have any conclusive answers on this
behavior of HMS.
# First event in list of notifications received from HMS greater than latest
sentry HMS notification Id. This is not true
## Event_ID in the NOTIFICATION_LOG table are not always ascending. Order of
sequence is not guaranteed.
## There can be gaps in between Event_ID's in the consecutive entries.
Here is what I think.
# when getCurrentNotificationEventId is not dependable why should HMSFollower
use it in the first place. Even with the fix that you provided HMSFollower
would wait for 5 sec(Default) to see if getCurrentNotificationEventId returns a
value greater than the last event id that sentry has processed. If not, full
snapshot is initiated. There is no guaranty that it would be greater by that
time. Sentry is not out of sync even if getCurrentNotificationEventId returns
an Id that is smaller than the last event id that sentry has processed. *Do you
agree?*
{color:blue}I prefer removing code in HMSFollower that depends on
getCurrentNotificationEventId to see if it out of sync with HMS.{color}
# Fix for SENTRY-2109 will address the 2nd assumption taken.
> Sentry ahead full snapshot retry logic
> --------------------------------------
>
> Key: SENTRY-2106
> URL: https://issues.apache.org/jira/browse/SENTRY-2106
> Project: Sentry
> Issue Type: New Feature
> Components: Sentry
> Affects Versions: 2.1.0
> Reporter: Arjun Mishra
> Assignee: Arjun Mishra
> Labels: features
> Fix For: 2.1.0
>
> Attachments: SENTRY-2106.01.patch, SENTRY-2106.02.patch,
> SENTRY-2106.03.patch
>
>
> Once SentryHMSNotification table is not empty, there are two cases when a
> full snapshot is triggered.
> # If first event in list of notifications received from HMS greater than
> latest sentry hms notification Id
> # If latest sentry notification Id is greater than current hms notification Id
> The later is a unexpected case where for some reason sentry gets ahead of
> HMS. We should add a logic to trigger a full snapshot in case 2 only after a
> configurable number of retries. This will avoid unnecessary full snapshot
> triggers as they are resource intensive
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
