[ https://issues.apache.org/jira/browse/SENTRY-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15882068#comment-15882068 ]
Alexander Kolbasov edited comment on SENTRY-1600 at 2/28/17 10:23 PM: ---------------------------------------------------------------------- Here is the proposed change to the thrift API: {code} /* * API for synchronizing between HMS notification events and Sentry. * * When Sentry gets updates from HMS using HMS Notifications, HMS should * should wait after each notification event is generated until the notification * is handled by Sentry This preserves the synchronous semantics of DDL statements. * * The notification synchronization API is private between HMS and Sentry and should * not be used by anything else. * * The API should be used in the following way: * * 1) HMS creates a notification and stores its ID in the persistent storage * 2) HMS sends ID to Sentry * 3) Sentry blocks the response until the specified ID is processed by Sentry * 4) Sentry responds with the most recent processed ID. * * Note that the important part is blocking in Sentry until the specified ID * is processed. The returned most recent processed ID is intended for debugging * purposes only, but may be used in HMS for performance optimizations. */ struct TSentrySyncIDRequest { 1: required i32 protocol_version = sentry_common_service.TSENTRY_SERVICE_V2, 2: required i64 id // Requested ID } struct TSentrySyncIDResponse { 1: required i64 id // Most recent processed ID } {code} And the new service call: {code} service SentryPolicyService { ... # Synchronize between HMS notifications and Sentry TSentrySyncIDResponse sentry_sync_notifications(1:TSentrySyncIDRequest request); } was (Author: akolb): Here is the proposed change to the thrift API: {code} /* * API for synchronizing between HMS notification events and Sentry. * * When Sentry gets updates from HMS using HMS Notifications, HMS should * should wait after each notification event is generated until the notification * is handled by Sentry This preserves the synchronous semantics of DDL statements. * * The notification synchronization API is private between HMS and Sentry and should * not be used by anything else. * * The API should be used in the following way: * * 1) HMS creates a notification and stores its ID in the persistent storage * 2) HMS sends ID to Sentry * 3) Sentry blocks the response until the specified ID is processed by Sentry * 4) Sentry responds with the most recent processed ID. * * Note that the important part is blocking in Sentry until the specified ID * is processed. The returned most recent processed ID is intended for debugging * purposes only, but may be used in HMS for performance optimizations. */ struct TSentrySyncIDRequest { 1: required i32 protocol_version = sentry_common_service.TSENTRY_SERVICE_V2, 2: required i64 id // Requested ID } struct TSentrySyncIDResponse { 1: required i64 id // Most recent processed ID } {code} And the new service call: {code} service SentryPolicyService { ... # Synchronize between HMS notifications and Sentry TSentrySyncIDResponse sentry_sync_notifications(1:TSentrySyncIDRequest request); } > Define Thrift API for HMS to Sentry notification barrier > -------------------------------------------------------- > > Key: SENTRY-1600 > URL: https://issues.apache.org/jira/browse/SENTRY-1600 > Project: Sentry > Issue Type: Sub-task > Components: Sentry > Affects Versions: sentry-ha-redesign > Reporter: Alexander Kolbasov > Assignee: Alexander Kolbasov > Fix For: sentry-ha-redesign > > Attachments: SENTRY-1600.001-sentry-ha-redesign.patch > > > When HMS performs its operations (e.g. create drop table) when Notifications > are used it should wait until HMS processes this notification. > This JIRA is about Thrift API for that. -- This message was sent by Atlassian JIRA (v6.3.15#6346)