[
https://issues.apache.org/jira/browse/SENTRY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16305618#comment-16305618
]
kalyan kumar kalvagadda edited comment on SENTRY-2109 at 12/28/17 6:08 PM:
---------------------------------------------------------------------------
*Here is the assumption that HMSFollower is currently taking.*
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.
[~vspector] I agree with you. Thus patch should be looked together with the
patch for SENTRY-2106. I have created this patch to perform some tests locally
using the patches for SENTRY-2106 and SENTRY-2109.
*What does being Sentry being out of sync with HMS mean?*
Sentry can not be up-to-date with HMS just by fetching new notifications and
processing them. Sentry has to start from scratch and create a full snapshot.
This patch does the following
Note: latestSentryNotificationId is the MAX of all the event-id's that sentry
processed.
# While requesting updates HMSFollower would request notification from
(latestSentryNotificationId -1)
# Normally when Sentry and HMS are in Sync, filter provided should also process
the notification with latestSentryNotificationId.
# When Sentry and HMS are out of Sync where HMS will not have the notification
event that was processed by sentry which is the notification event with
event-id latestSentryNotificationId. This indicates that there are
notifications missing.
Note: This is an extension to current logic of identifying and processing
notifications with same event-id's.
was (Author: kkalyan):
*Here is the assumption that HMSFollower is currently taking.*
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.
[~vspector] I agree with you. Thus patch should be looked together with the
patch for SENTRY-2106. I have created this patch to perform some tests locally
using the patches for SENTRY-2106 and SENTRY-2109.
*What does being Sentry being out of sync with HMS mean?*
Sentry can not be up-to-date with HMS just by fetching new notifications and
processing them. Sentry has to start from scratch and create a full snapshot.
This patch does the following
Note: latestSentryNotificationId is the MAX of all the event-id's that sentry
processed.
# While requesting updates HMSFollower would request notification from
(latestSentryNotificationId -1)
# Normally when Sentry and HMS are in Sync, filter provided should also process
the notification with latestSentryNotificationId.
# When Sentry and HMS are out of Sync where HMS will not have the notification
event that was processed by sentry which is the notification event with
event-id latestSentryNotificationId. This indicates that there are
notifications missing.
> Fix the logic of identifying HMS out of Sync
> --------------------------------------------
>
> Key: SENTRY-2109
> URL: https://issues.apache.org/jira/browse/SENTRY-2109
> Project: Sentry
> Issue Type: Bug
> Components: Sentry
> Affects Versions: 2.1.0
> Reporter: kalyan kumar kalvagadda
> Assignee: kalyan kumar kalvagadda
> Fix For: 2.1.0
>
> Attachments: SENTRY-2109.001.patch,
> Screenshot_HMS_NOTIFICATION_LOG.png
>
>
> Currently HMSFollower proactively checks if sentry is out of sync with HMS
> and initiates full snapshot, if needed.
> There will be false positives with the current logic if there are gaps in the
> event-id in the notification log sequence.
> This jira is aimed at making that logic robust.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
