[
https://issues.apache.org/jira/browse/SENTRY-1888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16139029#comment-16139029
]
Alexander Kolbasov commented on SENTRY-1888:
--------------------------------------------
What do you mean by
{quote}
"The SQL execution order determines the end result, not the transaction commit
order. "?
{quote}
Can you post your experiments somewhere so that we can better understand what
is happening?
Are you saying that it doesn't matter when transactions commit?
In 2) "If the NotificationID is fetched and increased right after the SQL
command for path update" - notification IDs are fetched from HMS using HMS API.
They come from HMS, not from Sentry. That's why we do care about their order.
> 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)
