[
https://issues.apache.org/jira/browse/SENTRY-1888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16139003#comment-16139003
]
Na Li commented on SENTRY-1888:
-------------------------------
[~akolb][~spena][~btowles] Brian and I did test on what order determines the
result in database.
1. The SQL execution order determins the end result, not the transaction commit
order. So it does not matter that "we cannot trust on those duplicates as they
will not know the order of the time they were committed"
2. If the NotificationID is fetched and increased right after the SQL command
for path update, the notificationID should closing track the order of SQL
execution order. If this is true, we should care about the notificationID
order, and should apply path changes using that order.
If you agree above reasoning, In following example
1) Sentry fetches 1,2 and applies them
2) Sentry fetches 1,2,2,3,4,5 (new IDs are 2,4,5).
We should apply 2,2,3,4,5 (one of the 2 is re-apply)
> Sentry might not fetch all HMS duplicated events IDs when requested
> -------------------------------------------------------------------
>
> Key: SENTRY-1888
> URL: https://issues.apache.org/jira/browse/SENTRY-1888
> Project: Sentry
> Issue Type: Bug
> Components: Sentry
> Affects Versions: 2.0.0
> Reporter: Sergio Peña
> Assignee: Sergio Peña
>
> HMS does not guarantee that each notification has unique IDs. SENTRY-1803
> solved the issue with Sentry to handle those duplicated events IDs. However,
> HMS notifications with duplicated events IDs could appear late on the HMS
> side due to delay issues on the DB (especially on HMS HA mode). These events
> could not be fetched by Sentry if we already processed a duplicated event ID
> before.
> Example:
> 1. HMS 1 attempts to persist event ID = 1
> 2. HMS 2 attempts to persist event ID = 1
> 3. HMS 1 commits event ID = 1
> 4. Sentry fetches notifications >= 1 (bringing the event from HMS 1)
> 5. HMS 2 commits event ID = 1
> 6. Sentry fetches notifications >= 2 (no events are fetched)
> HMS 2 event ID = 1 is never fetched nor processed by Sentry.
> The above scenario could cause Sentry to be out-of-sync because of these
> events that were not committed on time.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
