[jira] [Commented] (SENTRY-2483) Implement HMS PreReadEvent support in MetastoreAuthzBinding
[
https://issues.apache.org/jira/browse/SENTRY-2483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754488#comment-16754488
]
Hadoop QA commented on SENTRY-2483:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12956622/SENTRY-2483.009.patch
against master.
{color:red}Overall:{color} -1 due to 3 errors
{color:red}ERROR:{color} mvn test exited 1
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.metastore.TestAuthorizingObjectStore
{color:red}ERROR:{color} Failed:
org.apache.sentry.tests.e2e.metastore.TestAuthorizingObjectStore
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4347/console
This message is automatically generated.
> Implement HMS PreReadEvent support in MetastoreAuthzBinding
> ---
>
> Key: SENTRY-2483
> URL: https://issues.apache.org/jira/browse/SENTRY-2483
> Project: Sentry
> Issue Type: Improvement
> Components: Sentry
>Reporter: Sergio Peña
>Assignee: Na Li
>Priority: Major
> Attachments: SENTRY-2483.003.patch, SENTRY-2483.004.patch,
> SENTRY-2483.004.patch, SENTRY-2483.005.patch, SENTRY-2483.006.patch,
> SENTRY-2483.007.patch, SENTRY-2483.008.patch, SENTRY-2483.009.patch,
> SENTRY-2483.1.patch, SENTRY-2483.2.patch, SENTRY-2483.2.patch,
> SENTRY-2483.2.patch, Test failure log for TestHDFSIntegrationWithHA in patch
> in SENTRY-2483.2.patch.txt
>
>
> MetastoreAuthzBinding has support for all HMS DDL events to verify if a user
> has the authorization to execute them. However, read event, such as
> READ_DATABASE and READ_TABLE are not supported.
> We should add support for them so HMS can have read authorization checks too.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SENTRY-2483) Implement HMS PreReadEvent support in MetastoreAuthzBinding
[ https://issues.apache.org/jira/browse/SENTRY-2483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Na Li updated SENTRY-2483: -- Attachment: SENTRY-2483.009.patch > Implement HMS PreReadEvent support in MetastoreAuthzBinding > --- > > Key: SENTRY-2483 > URL: https://issues.apache.org/jira/browse/SENTRY-2483 > Project: Sentry > Issue Type: Improvement > Components: Sentry >Reporter: Sergio Peña >Assignee: Na Li >Priority: Major > Attachments: SENTRY-2483.003.patch, SENTRY-2483.004.patch, > SENTRY-2483.004.patch, SENTRY-2483.005.patch, SENTRY-2483.006.patch, > SENTRY-2483.007.patch, SENTRY-2483.008.patch, SENTRY-2483.009.patch, > SENTRY-2483.1.patch, SENTRY-2483.2.patch, SENTRY-2483.2.patch, > SENTRY-2483.2.patch, Test failure log for TestHDFSIntegrationWithHA in patch > in SENTRY-2483.2.patch.txt > > > MetastoreAuthzBinding has support for all HMS DDL events to verify if a user > has the authorization to execute them. However, read event, such as > READ_DATABASE and READ_TABLE are not supported. > We should add support for them so HMS can have read authorization checks too. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SENTRY-2488) Add privilege cache to sentry hive bindings in DefaultAccessValidator
[ https://issues.apache.org/jira/browse/SENTRY-2488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754371#comment-16754371 ] Arjun Mishra commented on SENTRY-2488: -- Tests are passing locally. Resubmitting the patch > Add privilege cache to sentry hive bindings in DefaultAccessValidator > - > > Key: SENTRY-2488 > URL: https://issues.apache.org/jira/browse/SENTRY-2488 > Project: Sentry > Issue Type: Improvement > Components: Sentry >Affects Versions: 2.1.0 >Reporter: Arjun Mishra >Assignee: Arjun Mishra >Priority: Major > Attachments: SENTRY-2488.0002.patch, SENTRY-2488.002.patch, > SENTRY-2488.01.patch, SENTRY-2488.02.patch > > > We are not consistent with behavior in SentryHiveMetaStoreHook (not used > anymore) which would cache privileges when authorizing show databases or show > tables command. This needs to be added back -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SENTRY-2488) Add privilege cache to sentry hive bindings in DefaultAccessValidator
[ https://issues.apache.org/jira/browse/SENTRY-2488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arjun Mishra updated SENTRY-2488: - Attachment: SENTRY-2488.0002.patch > Add privilege cache to sentry hive bindings in DefaultAccessValidator > - > > Key: SENTRY-2488 > URL: https://issues.apache.org/jira/browse/SENTRY-2488 > Project: Sentry > Issue Type: Improvement > Components: Sentry >Affects Versions: 2.1.0 >Reporter: Arjun Mishra >Assignee: Arjun Mishra >Priority: Major > Attachments: SENTRY-2488.0002.patch, SENTRY-2488.002.patch, > SENTRY-2488.01.patch, SENTRY-2488.02.patch > > > We are not consistent with behavior in SentryHiveMetaStoreHook (not used > anymore) which would cache privileges when authorizing show databases or show > tables command. This needs to be added back -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SENTRY-2483) Implement HMS PreReadEvent support in MetastoreAuthzBinding
[ https://issues.apache.org/jira/browse/SENTRY-2483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Na Li updated SENTRY-2483: -- Attachment: SENTRY-2483.008.patch > Implement HMS PreReadEvent support in MetastoreAuthzBinding > --- > > Key: SENTRY-2483 > URL: https://issues.apache.org/jira/browse/SENTRY-2483 > Project: Sentry > Issue Type: Improvement > Components: Sentry >Reporter: Sergio Peña >Assignee: Na Li >Priority: Major > Attachments: SENTRY-2483.003.patch, SENTRY-2483.004.patch, > SENTRY-2483.004.patch, SENTRY-2483.005.patch, SENTRY-2483.006.patch, > SENTRY-2483.007.patch, SENTRY-2483.008.patch, SENTRY-2483.1.patch, > SENTRY-2483.2.patch, SENTRY-2483.2.patch, SENTRY-2483.2.patch, Test failure > log for TestHDFSIntegrationWithHA in patch in SENTRY-2483.2.patch.txt > > > MetastoreAuthzBinding has support for all HMS DDL events to verify if a user > has the authorization to execute them. However, read event, such as > READ_DATABASE and READ_TABLE are not supported. > We should add support for them so HMS can have read authorization checks too. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SENTRY-2486) Wrong user name when sentry HMSFollower gets full snapshot from HMS at insecure mode
[
https://issues.apache.org/jira/browse/SENTRY-2486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754336#comment-16754336
]
Hadoop QA commented on SENTRY-2486:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12956596/SENTRY-2486.002.patch
against master.
{color:green}Overall:{color} +1 all checks pass
{color:green}SUCCESS:{color} all tests passed
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4344/console
This message is automatically generated.
> Wrong user name when sentry HMSFollower gets full snapshot from HMS at
> insecure mode
>
>
> Key: SENTRY-2486
> URL: https://issues.apache.org/jira/browse/SENTRY-2486
> Project: Sentry
> Issue Type: Bug
> Components: Sentry
>Affects Versions: 2.2.0
>Reporter: Na Li
>Assignee: Na Li
>Priority: Major
> Attachments: SENTRY-2486.001.patch, SENTRY-2486.001.patch,
> SENTRY-2486.002.patch
>
>
> In insecure mode, the current login user name is passed from Sentry to HMS
> server when sentry HMSFollower gets full snapshot from HMS.
> The user name should be "sentry" instead of current login user.
> The followiong code shows how current login user name is used when subject is
> null.
> In UserGroupInformation, if the context does not have subject, the
> getLoginUser() is used as user name
> @Public
> @Evolving
> public static UserGroupInformation getCurrentUser() throws IOException {
> AccessControlContext context = AccessController.getContext();
> Subject subject = Subject.getSubject(context);
> return subject != null && !subject.getPrincipals(User.class).isEmpty() ?
> new UserGroupInformation(subject) : getLoginUser();
> }
> This issue should not happen in production because secure mode is always
> used. Insecure mode is only used in test.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SENTRY-2490) When building a full perm update for each object we only build 1 privilege per role
[ https://issues.apache.org/jira/browse/SENTRY-2490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754299#comment-16754299 ] kalyan kumar kalvagadda commented on SENTRY-2490: - code change looks good. > When building a full perm update for each object we only build 1 privilege > per role > --- > > Key: SENTRY-2490 > URL: https://issues.apache.org/jira/browse/SENTRY-2490 > Project: Sentry > Issue Type: Bug > Components: Sentry >Affects Versions: 2.1.0 >Reporter: Arjun Mishra >Assignee: Arjun Mishra >Priority: Major > Attachments: SENTRY-2490.01.patch > > > When building a perm full update we only include one privilege a role has on > an object as opposed to the entire privilege set -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SENTRY-2491) Sentry High availability unit tests run into deadlock sometimes
[
https://issues.apache.org/jira/browse/SENTRY-2491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754233#comment-16754233
]
Hadoop QA commented on SENTRY-2491:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12956584/SENTRY-2491.002.patch
against master.
{color:red}Overall:{color} -1 due to an error
{color:red}ERROR:{color} mvn test exited 1
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4342/console
This message is automatically generated.
> Sentry High availability unit tests run into deadlock sometimes
> ---
>
> Key: SENTRY-2491
> URL: https://issues.apache.org/jira/browse/SENTRY-2491
> Project: Sentry
> Issue Type: Bug
> Components: Sentry
>Affects Versions: 2.2.0
>Reporter: Na Li
>Assignee: Na Li
>Priority: Major
> Attachments: SENTRY-2491.001.patch, SENTRY-2491.002.patch,
> SENTRY-2491.002.patch, SENTRY-2491.002.patch, SENTRY-2491.002.patch,
> SENTRY-2491.003.patch
>
>
> In sentry unit tests, we don't create schema before running a test. Instead,
> we use dataNucleus to create sentry tables when they are accessed. This
> creates potential deadlock when running test for Sentry HA setup.
> For example, the following shows the event sequence that causes deadlock
> 1) thread_1 gets shared lock of SYSTABLES in order to read table
> SENTRY_HMS_NOTIFICATION_ID
> 2) thread_2 gets shared lock of SYSTABLES in order to read table
> SENTRY_HMS_NOTIFICATION_ID
> 3) thread_1 tries to get execution lock to create table
> SENTRY_HMS_NOTIFICATION_ID,
>and wait for execution lock because thread_2 got shared lock already.
> 4) thread_2 tries to get execution lock to create table
> SENTRY_HMS_NOTIFICATION_ID,
>and wait for execution lock because thread_1 got shared lock already.
> The solution is to let the instances of sentry service start with delay.
> Specifically,
> let HMS follower threads separate as far as possible, i.e., half of the
> interval.
>
> This deadlock only exists in unit tests, and does not exist in production
> because schema is created before starting Sentry services. Therefore, there
> is no table creation after service starts.
> Example of the log message when such deadlock happens
> {code}
> 2019-01-04 18:32:46,332 (pool-13-thread-1) [INFO -
> org.apache.sentry.hdfs.DBUpdateForwarder.getAllUpdatesFrom(DBUpdateForwarder.java:140)]
> (org.apache.sentry.hdfs.PermImageRetriever) Requested sequence number 0 is
> less than 0 or requested deltas for that sequence number are not available.
> Fetch a full update
> 2019-01-04 18:32:49,346 (hms-follower) [DEBUG -
> org.apache.sentry.service.thrift.SentryStateBank.enableState(SentryStateBank.java:102)]
> HMSFollower entered state STARTED
> 2019-01-04 18:32:50,091 (hms-follower) [DEBUG -
> org.apache.sentry.service.thrift.SentryStateBank.enableState(SentryStateBank.java:102)]
> HMSFollower entered state STARTED
> 2019-01-04 18:33:00,286 (store-cleaner) [ERROR -
> org.datanucleus.util.Log4JLogger.error(Log4JLogger.java:115)] Error thrown
> executing CREATE TABLE SENTRY_HMS_NOTIFICATION_ID
> (
> NOTIFICATION_ID BIGINT NOT NULL
> ) : A lock could not be obtained due to a deadlock, cycle of locks and
> waiters is:
> Lock : ROW, SYSTABLES, (1,3)
> Waiting XID : {436, X} , SENTRY, CREATE TABLE SENTRY_HMS_NOTIFICATION_ID
> (
> NOTIFICATION_ID BIGINT NOT NULL
> )
> Granted XID : {419, S}
> Lock : ROW, SYSTABLES, (1,3)
> Waiting XID : {419, X} , SENTRY, CREATE TABLE SENTRY_HMS_NOTIFICATION_ID
> (
> NOTIFICATION_ID BIGINT NOT NULL
> )
> Granted XID : {419, S} , {436, S}
> . The selected victim is XID : 436.
> java.sql.SQLTransactionRollbackException: A lock could not be obtained due to
> a deadlock, cycle of locks and waiters is:
> Lock : ROW, SYSTABLES, (1,3)
> Waiting XID : {436, X} , SENTRY, CREATE TABLE SENTRY_HMS_NOTIFICATION_ID
> (
> NOTIFICATION_ID BIGINT NOT NULL
> )
> Granted XID : {419, S}
> Lock : ROW, SYSTABLES, (1,3)
> Waiting XID : {419, X} , SENTRY, CREATE TABLE SENTRY_HMS_NOTIFICATION_ID
> (
> NOTIFICATION_ID BIGINT NOT NULL
> )
> Granted XID : {419, S} , {436, S}
> . The selected victim is XID : 436.
> at
> org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
> at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown
> Source)
> at
> org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown
> Source)
> at
> org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown
> Source)
> at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown
> Source)
>
[jira] [Commented] (SENTRY-2491) Sentry High availability unit tests run into deadlock sometimes
[
https://issues.apache.org/jira/browse/SENTRY-2491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754220#comment-16754220
]
Hadoop QA commented on SENTRY-2491:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12956586/SENTRY-2491.003.patch
against master.
{color:green}Overall:{color} +1 all checks pass
{color:green}SUCCESS:{color} all tests passed
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4343/console
This message is automatically generated.
> Sentry High availability unit tests run into deadlock sometimes
> ---
>
> Key: SENTRY-2491
> URL: https://issues.apache.org/jira/browse/SENTRY-2491
> Project: Sentry
> Issue Type: Bug
> Components: Sentry
>Affects Versions: 2.2.0
>Reporter: Na Li
>Assignee: Na Li
>Priority: Major
> Attachments: SENTRY-2491.001.patch, SENTRY-2491.002.patch,
> SENTRY-2491.002.patch, SENTRY-2491.002.patch, SENTRY-2491.002.patch,
> SENTRY-2491.003.patch
>
>
> In sentry unit tests, we don't create schema before running a test. Instead,
> we use dataNucleus to create sentry tables when they are accessed. This
> creates potential deadlock when running test for Sentry HA setup.
> For example, the following shows the event sequence that causes deadlock
> 1) thread_1 gets shared lock of SYSTABLES in order to read table
> SENTRY_HMS_NOTIFICATION_ID
> 2) thread_2 gets shared lock of SYSTABLES in order to read table
> SENTRY_HMS_NOTIFICATION_ID
> 3) thread_1 tries to get execution lock to create table
> SENTRY_HMS_NOTIFICATION_ID,
>and wait for execution lock because thread_2 got shared lock already.
> 4) thread_2 tries to get execution lock to create table
> SENTRY_HMS_NOTIFICATION_ID,
>and wait for execution lock because thread_1 got shared lock already.
> The solution is to let the instances of sentry service start with delay.
> Specifically,
> let HMS follower threads separate as far as possible, i.e., half of the
> interval.
>
> This deadlock only exists in unit tests, and does not exist in production
> because schema is created before starting Sentry services. Therefore, there
> is no table creation after service starts.
> Example of the log message when such deadlock happens
> {code}
> 2019-01-04 18:32:46,332 (pool-13-thread-1) [INFO -
> org.apache.sentry.hdfs.DBUpdateForwarder.getAllUpdatesFrom(DBUpdateForwarder.java:140)]
> (org.apache.sentry.hdfs.PermImageRetriever) Requested sequence number 0 is
> less than 0 or requested deltas for that sequence number are not available.
> Fetch a full update
> 2019-01-04 18:32:49,346 (hms-follower) [DEBUG -
> org.apache.sentry.service.thrift.SentryStateBank.enableState(SentryStateBank.java:102)]
> HMSFollower entered state STARTED
> 2019-01-04 18:32:50,091 (hms-follower) [DEBUG -
> org.apache.sentry.service.thrift.SentryStateBank.enableState(SentryStateBank.java:102)]
> HMSFollower entered state STARTED
> 2019-01-04 18:33:00,286 (store-cleaner) [ERROR -
> org.datanucleus.util.Log4JLogger.error(Log4JLogger.java:115)] Error thrown
> executing CREATE TABLE SENTRY_HMS_NOTIFICATION_ID
> (
> NOTIFICATION_ID BIGINT NOT NULL
> ) : A lock could not be obtained due to a deadlock, cycle of locks and
> waiters is:
> Lock : ROW, SYSTABLES, (1,3)
> Waiting XID : {436, X} , SENTRY, CREATE TABLE SENTRY_HMS_NOTIFICATION_ID
> (
> NOTIFICATION_ID BIGINT NOT NULL
> )
> Granted XID : {419, S}
> Lock : ROW, SYSTABLES, (1,3)
> Waiting XID : {419, X} , SENTRY, CREATE TABLE SENTRY_HMS_NOTIFICATION_ID
> (
> NOTIFICATION_ID BIGINT NOT NULL
> )
> Granted XID : {419, S} , {436, S}
> . The selected victim is XID : 436.
> java.sql.SQLTransactionRollbackException: A lock could not be obtained due to
> a deadlock, cycle of locks and waiters is:
> Lock : ROW, SYSTABLES, (1,3)
> Waiting XID : {436, X} , SENTRY, CREATE TABLE SENTRY_HMS_NOTIFICATION_ID
> (
> NOTIFICATION_ID BIGINT NOT NULL
> )
> Granted XID : {419, S}
> Lock : ROW, SYSTABLES, (1,3)
> Waiting XID : {419, X} , SENTRY, CREATE TABLE SENTRY_HMS_NOTIFICATION_ID
> (
> NOTIFICATION_ID BIGINT NOT NULL
> )
> Granted XID : {419, S} , {436, S}
> . The selected victim is XID : 436.
> at
> org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
> at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown
> Source)
> at
> org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown
> Source)
> at
> org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown
> Source)
> at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown
>
[jira] [Updated] (SENTRY-2491) Sentry High availability unit tests run into deadlock sometimes
[
https://issues.apache.org/jira/browse/SENTRY-2491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Na Li updated SENTRY-2491:
--
Attachment: SENTRY-2491.003.patch
> Sentry High availability unit tests run into deadlock sometimes
> ---
>
> Key: SENTRY-2491
> URL: https://issues.apache.org/jira/browse/SENTRY-2491
> Project: Sentry
> Issue Type: Bug
> Components: Sentry
>Affects Versions: 2.2.0
>Reporter: Na Li
>Assignee: Na Li
>Priority: Major
> Attachments: SENTRY-2491.001.patch, SENTRY-2491.002.patch,
> SENTRY-2491.002.patch, SENTRY-2491.002.patch, SENTRY-2491.002.patch,
> SENTRY-2491.003.patch
>
>
> In sentry unit tests, we don't create schema before running a test. Instead,
> we use dataNucleus to create sentry tables when they are accessed. This
> creates potential deadlock when running test for Sentry HA setup.
> For example, the following shows the event sequence that causes deadlock
> 1) thread_1 gets shared lock of SYSTABLES in order to read table
> SENTRY_HMS_NOTIFICATION_ID
> 2) thread_2 gets shared lock of SYSTABLES in order to read table
> SENTRY_HMS_NOTIFICATION_ID
> 3) thread_1 tries to get execution lock to create table
> SENTRY_HMS_NOTIFICATION_ID,
>and wait for execution lock because thread_2 got shared lock already.
> 4) thread_2 tries to get execution lock to create table
> SENTRY_HMS_NOTIFICATION_ID,
>and wait for execution lock because thread_1 got shared lock already.
> The solution is to let the instances of sentry service start with delay.
> Specifically,
> let HMS follower threads separate as far as possible, i.e., half of the
> interval.
>
> This deadlock only exists in unit tests, and does not exist in production
> because schema is created before starting Sentry services. Therefore, there
> is no table creation after service starts.
> Example of the log message when such deadlock happens
> {code}
> 2019-01-04 18:32:46,332 (pool-13-thread-1) [INFO -
> org.apache.sentry.hdfs.DBUpdateForwarder.getAllUpdatesFrom(DBUpdateForwarder.java:140)]
> (org.apache.sentry.hdfs.PermImageRetriever) Requested sequence number 0 is
> less than 0 or requested deltas for that sequence number are not available.
> Fetch a full update
> 2019-01-04 18:32:49,346 (hms-follower) [DEBUG -
> org.apache.sentry.service.thrift.SentryStateBank.enableState(SentryStateBank.java:102)]
> HMSFollower entered state STARTED
> 2019-01-04 18:32:50,091 (hms-follower) [DEBUG -
> org.apache.sentry.service.thrift.SentryStateBank.enableState(SentryStateBank.java:102)]
> HMSFollower entered state STARTED
> 2019-01-04 18:33:00,286 (store-cleaner) [ERROR -
> org.datanucleus.util.Log4JLogger.error(Log4JLogger.java:115)] Error thrown
> executing CREATE TABLE SENTRY_HMS_NOTIFICATION_ID
> (
> NOTIFICATION_ID BIGINT NOT NULL
> ) : A lock could not be obtained due to a deadlock, cycle of locks and
> waiters is:
> Lock : ROW, SYSTABLES, (1,3)
> Waiting XID : {436, X} , SENTRY, CREATE TABLE SENTRY_HMS_NOTIFICATION_ID
> (
> NOTIFICATION_ID BIGINT NOT NULL
> )
> Granted XID : {419, S}
> Lock : ROW, SYSTABLES, (1,3)
> Waiting XID : {419, X} , SENTRY, CREATE TABLE SENTRY_HMS_NOTIFICATION_ID
> (
> NOTIFICATION_ID BIGINT NOT NULL
> )
> Granted XID : {419, S} , {436, S}
> . The selected victim is XID : 436.
> java.sql.SQLTransactionRollbackException: A lock could not be obtained due to
> a deadlock, cycle of locks and waiters is:
> Lock : ROW, SYSTABLES, (1,3)
> Waiting XID : {436, X} , SENTRY, CREATE TABLE SENTRY_HMS_NOTIFICATION_ID
> (
> NOTIFICATION_ID BIGINT NOT NULL
> )
> Granted XID : {419, S}
> Lock : ROW, SYSTABLES, (1,3)
> Waiting XID : {419, X} , SENTRY, CREATE TABLE SENTRY_HMS_NOTIFICATION_ID
> (
> NOTIFICATION_ID BIGINT NOT NULL
> )
> Granted XID : {419, S} , {436, S}
> . The selected victim is XID : 436.
> at
> org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
> at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown
> Source)
> at
> org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown
> Source)
> at
> org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown
> Source)
> at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source)
> at com.jolbox.bonecp.StatementHandle.execute(StatementHandle.java:254)
> at
>
[jira] [Assigned] (SENTRY-2205) Improve Sentry NN Logging
[ https://issues.apache.org/jira/browse/SENTRY-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] kalyan kumar kalvagadda reassigned SENTRY-2205: --- Assignee: kalyan kumar kalvagadda (was: Arjun Mishra) > Improve Sentry NN Logging > - > > Key: SENTRY-2205 > URL: https://issues.apache.org/jira/browse/SENTRY-2205 > Project: Sentry > Issue Type: Bug > Components: Sentry >Affects Versions: 2.1.0 >Reporter: Arjun Mishra >Assignee: kalyan kumar kalvagadda >Priority: Major > > Logging in SentryAuthorizationInfo, UpdateForwarder, and SentryStore classes > are weak and make debugging hard. Improve logging in these classes -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SENTRY-2491) Sentry High availability unit tests run into deadlock sometimes
[
https://issues.apache.org/jira/browse/SENTRY-2491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754059#comment-16754059
]
Na Li commented on SENTRY-2491:
---
The failure was not due to test failure. Instead it is because failed to
execute maven plugin. It is not related to my code change. Re-attach the patch
again
{code}
03:56:24 [ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.20.1:test (default-test) on
project sentry-tests-hive: There was a timeout or other error in the fork ->
[Help 1]
03:56:24 [ERROR]
03:56:24 [ERROR] To see the full stack trace of the errors, re-run Maven with
the -e switch.
03:56:24 [ERROR] Re-run Maven using the -X switch to enable full debug logging.
03:56:24 [ERROR]
03:56:24 [ERROR] For more information about the errors and possible solutions,
please read the following articles:
03:56:24 [ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
03:56:24 [ERROR]
03:56:24 [ERROR] After correcting the problems, you can resume the build with
the command
03:56:24 [ERROR] mvn -rf :sentry-tests-hive
{code}
> Sentry High availability unit tests run into deadlock sometimes
> ---
>
> Key: SENTRY-2491
> URL: https://issues.apache.org/jira/browse/SENTRY-2491
> Project: Sentry
> Issue Type: Bug
> Components: Sentry
>Affects Versions: 2.2.0
>Reporter: Na Li
>Assignee: Na Li
>Priority: Major
> Attachments: SENTRY-2491.001.patch, SENTRY-2491.002.patch,
> SENTRY-2491.002.patch, SENTRY-2491.002.patch, SENTRY-2491.002.patch
>
>
> In sentry unit tests, we don't create schema before running a test. Instead,
> we use dataNucleus to create sentry tables when they are accessed. This
> creates potential deadlock when running test for Sentry HA setup.
> For example, the following shows the event sequence that causes deadlock
> 1) thread_1 gets shared lock of SYSTABLES in order to read table
> SENTRY_HMS_NOTIFICATION_ID
> 2) thread_2 gets shared lock of SYSTABLES in order to read table
> SENTRY_HMS_NOTIFICATION_ID
> 3) thread_1 tries to get execution lock to create table
> SENTRY_HMS_NOTIFICATION_ID,
>and wait for execution lock because thread_2 got shared lock already.
> 4) thread_2 tries to get execution lock to create table
> SENTRY_HMS_NOTIFICATION_ID,
>and wait for execution lock because thread_1 got shared lock already.
> The solution is to let the instances of sentry service start with delay.
> Specifically,
> let HMS follower threads separate as far as possible, i.e., half of the
> interval.
>
> This deadlock only exists in unit tests, and does not exist in production
> because schema is created before starting Sentry services. Therefore, there
> is no table creation after service starts.
> Example of the log message when such deadlock happens
> {code}
> 2019-01-04 18:32:46,332 (pool-13-thread-1) [INFO -
> org.apache.sentry.hdfs.DBUpdateForwarder.getAllUpdatesFrom(DBUpdateForwarder.java:140)]
> (org.apache.sentry.hdfs.PermImageRetriever) Requested sequence number 0 is
> less than 0 or requested deltas for that sequence number are not available.
> Fetch a full update
> 2019-01-04 18:32:49,346 (hms-follower) [DEBUG -
> org.apache.sentry.service.thrift.SentryStateBank.enableState(SentryStateBank.java:102)]
> HMSFollower entered state STARTED
> 2019-01-04 18:32:50,091 (hms-follower) [DEBUG -
> org.apache.sentry.service.thrift.SentryStateBank.enableState(SentryStateBank.java:102)]
> HMSFollower entered state STARTED
> 2019-01-04 18:33:00,286 (store-cleaner) [ERROR -
> org.datanucleus.util.Log4JLogger.error(Log4JLogger.java:115)] Error thrown
> executing CREATE TABLE SENTRY_HMS_NOTIFICATION_ID
> (
> NOTIFICATION_ID BIGINT NOT NULL
> ) : A lock could not be obtained due to a deadlock, cycle of locks and
> waiters is:
> Lock : ROW, SYSTABLES, (1,3)
> Waiting XID : {436, X} , SENTRY, CREATE TABLE SENTRY_HMS_NOTIFICATION_ID
> (
> NOTIFICATION_ID BIGINT NOT NULL
> )
> Granted XID : {419, S}
> Lock : ROW, SYSTABLES, (1,3)
> Waiting XID : {419, X} , SENTRY, CREATE TABLE SENTRY_HMS_NOTIFICATION_ID
> (
> NOTIFICATION_ID BIGINT NOT NULL
> )
> Granted XID : {419, S} , {436, S}
> . The selected victim is XID : 436.
> java.sql.SQLTransactionRollbackException: A lock could not be obtained due to
> a deadlock, cycle of locks and waiters is:
> Lock : ROW, SYSTABLES, (1,3)
> Waiting XID : {436, X} , SENTRY, CREATE TABLE SENTRY_HMS_NOTIFICATION_ID
> (
> NOTIFICATION_ID BIGINT NOT NULL
> )
> Granted XID : {419, S}
> Lock : ROW, SYSTABLES, (1,3)
> Waiting XID : {419, X} , SENTRY, CREATE TABLE SENTRY_HMS_NOTIFICATION_ID
> (
> NOTIFICATION_ID BIGINT NOT NULL
> )
> Granted XID : {419, S} , {436, S}
> . The selected victim is XID : 436.
>
[jira] [Updated] (SENTRY-2491) Sentry High availability unit tests run into deadlock sometimes
[
https://issues.apache.org/jira/browse/SENTRY-2491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Na Li updated SENTRY-2491:
--
Attachment: SENTRY-2491.002.patch
> Sentry High availability unit tests run into deadlock sometimes
> ---
>
> Key: SENTRY-2491
> URL: https://issues.apache.org/jira/browse/SENTRY-2491
> Project: Sentry
> Issue Type: Bug
> Components: Sentry
>Affects Versions: 2.2.0
>Reporter: Na Li
>Assignee: Na Li
>Priority: Major
> Attachments: SENTRY-2491.001.patch, SENTRY-2491.002.patch,
> SENTRY-2491.002.patch, SENTRY-2491.002.patch, SENTRY-2491.002.patch
>
>
> In sentry unit tests, we don't create schema before running a test. Instead,
> we use dataNucleus to create sentry tables when they are accessed. This
> creates potential deadlock when running test for Sentry HA setup.
> For example, the following shows the event sequence that causes deadlock
> 1) thread_1 gets shared lock of SYSTABLES in order to read table
> SENTRY_HMS_NOTIFICATION_ID
> 2) thread_2 gets shared lock of SYSTABLES in order to read table
> SENTRY_HMS_NOTIFICATION_ID
> 3) thread_1 tries to get execution lock to create table
> SENTRY_HMS_NOTIFICATION_ID,
>and wait for execution lock because thread_2 got shared lock already.
> 4) thread_2 tries to get execution lock to create table
> SENTRY_HMS_NOTIFICATION_ID,
>and wait for execution lock because thread_1 got shared lock already.
> The solution is to let the instances of sentry service start with delay.
> Specifically,
> let HMS follower threads separate as far as possible, i.e., half of the
> interval.
>
> This deadlock only exists in unit tests, and does not exist in production
> because schema is created before starting Sentry services. Therefore, there
> is no table creation after service starts.
> Example of the log message when such deadlock happens
> {code}
> 2019-01-04 18:32:46,332 (pool-13-thread-1) [INFO -
> org.apache.sentry.hdfs.DBUpdateForwarder.getAllUpdatesFrom(DBUpdateForwarder.java:140)]
> (org.apache.sentry.hdfs.PermImageRetriever) Requested sequence number 0 is
> less than 0 or requested deltas for that sequence number are not available.
> Fetch a full update
> 2019-01-04 18:32:49,346 (hms-follower) [DEBUG -
> org.apache.sentry.service.thrift.SentryStateBank.enableState(SentryStateBank.java:102)]
> HMSFollower entered state STARTED
> 2019-01-04 18:32:50,091 (hms-follower) [DEBUG -
> org.apache.sentry.service.thrift.SentryStateBank.enableState(SentryStateBank.java:102)]
> HMSFollower entered state STARTED
> 2019-01-04 18:33:00,286 (store-cleaner) [ERROR -
> org.datanucleus.util.Log4JLogger.error(Log4JLogger.java:115)] Error thrown
> executing CREATE TABLE SENTRY_HMS_NOTIFICATION_ID
> (
> NOTIFICATION_ID BIGINT NOT NULL
> ) : A lock could not be obtained due to a deadlock, cycle of locks and
> waiters is:
> Lock : ROW, SYSTABLES, (1,3)
> Waiting XID : {436, X} , SENTRY, CREATE TABLE SENTRY_HMS_NOTIFICATION_ID
> (
> NOTIFICATION_ID BIGINT NOT NULL
> )
> Granted XID : {419, S}
> Lock : ROW, SYSTABLES, (1,3)
> Waiting XID : {419, X} , SENTRY, CREATE TABLE SENTRY_HMS_NOTIFICATION_ID
> (
> NOTIFICATION_ID BIGINT NOT NULL
> )
> Granted XID : {419, S} , {436, S}
> . The selected victim is XID : 436.
> java.sql.SQLTransactionRollbackException: A lock could not be obtained due to
> a deadlock, cycle of locks and waiters is:
> Lock : ROW, SYSTABLES, (1,3)
> Waiting XID : {436, X} , SENTRY, CREATE TABLE SENTRY_HMS_NOTIFICATION_ID
> (
> NOTIFICATION_ID BIGINT NOT NULL
> )
> Granted XID : {419, S}
> Lock : ROW, SYSTABLES, (1,3)
> Waiting XID : {419, X} , SENTRY, CREATE TABLE SENTRY_HMS_NOTIFICATION_ID
> (
> NOTIFICATION_ID BIGINT NOT NULL
> )
> Granted XID : {419, S} , {436, S}
> . The selected victim is XID : 436.
> at
> org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
> at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown
> Source)
> at
> org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown
> Source)
> at
> org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown
> Source)
> at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source)
> at com.jolbox.bonecp.StatementHandle.execute(StatementHandle.java:254)
> at
>
[jira] [Commented] (SENTRY-2490) When building a full perm update for each object we only build 1 privilege per role
[
https://issues.apache.org/jira/browse/SENTRY-2490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16753791#comment-16753791
]
Hadoop QA commented on SENTRY-2490:
---
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12956531/SENTRY-2490.01.patch
against master.
{color:green}Overall:{color} +1 all checks pass
{color:green}SUCCESS:{color} all tests passed
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/4341/console
This message is automatically generated.
> When building a full perm update for each object we only build 1 privilege
> per role
> ---
>
> Key: SENTRY-2490
> URL: https://issues.apache.org/jira/browse/SENTRY-2490
> Project: Sentry
> Issue Type: Bug
> Components: Sentry
>Affects Versions: 2.1.0
>Reporter: Arjun Mishra
>Assignee: Arjun Mishra
>Priority: Major
> Attachments: SENTRY-2490.01.patch
>
>
> When building a perm full update we only include one privilege a role has on
> an object as opposed to the entire privilege set
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
