[ 
https://issues.apache.org/jira/browse/SENTRY-2305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16645873#comment-16645873
 ] 

Hadoop QA commented on SENTRY-2305:
-----------------------------------

Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12943320/SENTRY-2305.004.patch 
against master.

{color:red}Overall:{color} -1 due to 4 errors

{color:red}ERROR:{color} mvn test exited 1
{color:red}ERROR:{color} Failed: 
org.apache.sentry.tests.e2e.dbprovider.TestOwnerPrivilegesWithGrantOption
{color:red}ERROR:{color} Failed: 
org.apache.sentry.tests.e2e.dbprovider.TestHmsNotificationProcessingWithOutSyncOnDrop
{color:red}ERROR:{color} Failed: 
org.apache.sentry.tests.e2e.dbprovider.TestDbPrivilegeCleanupOnDrop

Console output: 
https://builds.apache.org/job/PreCommit-SENTRY-Build/4176/console

This message is automatically generated.

> Optimize time taken for persistence HMS snapshot by persisting in parallel
> --------------------------------------------------------------------------
>
>                 Key: SENTRY-2305
>                 URL: https://issues.apache.org/jira/browse/SENTRY-2305
>             Project: Sentry
>          Issue Type: Sub-task
>          Components: Sentry
>    Affects Versions: 2.1.0
>            Reporter: kalyan kumar kalvagadda
>            Assignee: kalyan kumar kalvagadda
>            Priority: Major
>         Attachments: SENTRY-2305.001.patch, SENTRY-2305.002.patch, 
> SENTRY-2305.003.patch, SENTRY-2305.004.patch
>
>
> There are couple of options
> # Break the total snapshot into to batches and persist all of them in 
> parallel in different transactions. As sentry uses repeatable_read isolation 
> level we should be able to have parallel writes on the same table. This bring 
> an issue if there is a failure in persisting any of the batches. This 
> approach needs additional logic of cleaning the partially persisted snapshot. 
> I’m evaluating this option. 
> ** *Result:* Initial results are promising. Time to persist the snapshot came 
> down by 60%.
> # Try disabling L1 Cache for persisting the snapshot.
> # Try persisting the snapshot entries sequentially in separate transactions. 
> As transactions which commit huge data might take longer as they take a lot 
> of CPU cycles to keep the rollback log up to date.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to