Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug report] drop kafka catalog maybe failed after altering #3673

Closed
mchades opened this issue May 30, 2024 · 0 comments · Fixed by #3672
Closed

[Bug report] drop kafka catalog maybe failed after altering #3673

mchades opened this issue May 30, 2024 · 0 comments · Fixed by #3672
Assignees
Labels
0.5.1 Release v0.5.1 0.6.0 Release v0.6.0 bug Something isn't working

Comments

@mchades
Copy link
Contributor

mchades commented May 30, 2024

Version

main branch

Describe what's wrong

drop kafka catalog maybe failed after altering

Error message and/or stacktrace

2024-05-30 14:25:24.197 [Gravitino-webserver-37] ERROR com.datastrato.gravitino.server.web.rest.ExceptionHandlers - Failed to operate object [test_catalog_836a3008] operation [DROP] under [catalogKafkaIT_metalake_94b63407], reason [Entity catalogKafkaIT_metalake_94b63407.test_catalog_836a3008 has sub-entities, you should remove sub-entities first]
com.datastrato.gravitino.exceptions.NonEmptyEntityException: Entity catalogKafkaIT_metalake_94b63407.test_catalog_836a3008 has sub-entities, you should remove sub-entities first
	at com.datastrato.gravitino.storage.relational.service.CatalogMetaService.deleteCatalog(CatalogMetaService.java:203) ~[gravitino-core-0.5.1-SNAPSHOT.jar:?]
	at com.datastrato.gravitino.storage.relational.JDBCBackend.delete(JDBCBackend.java:179) ~[gravitino-core-0.5.1-SNAPSHOT.jar:?]

How to reproduce

  • create a kafka catalog
  • alter the catalog
  • drop the catalog

Additional context

CatalogKafkaIT accidentally triggered

CatalogKafkaIT > testCatalog() FAILED
    org.opentest4j.AssertionFailedError: expected: <true> but was: <false>
        at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55)
        at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:40)
        at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:35)
        at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:179)
        at app//com.datastrato.gravitino.catalog.kafka.integration.test.CatalogKafkaIT.testCatalog(CatalogKafkaIT.java:142)

It's because catalogOps was not initialized originally, and the asynchronous thread that eliminated the catalog cache made another initialization to close catalogOps, resulting in the default schema being created again.

The deletion logic of the Kafka catalog is as follows:

@mchades mchades added the bug Something isn't working label May 30, 2024
@mchades mchades self-assigned this May 30, 2024
@mchades mchades added 0.5.1 Release v0.5.1 0.6.0 Release v0.6.0 labels May 30, 2024
yuqi1129 pushed a commit that referenced this issue May 31, 2024
…og (#3672)

### What changes were proposed in this pull request?

avoid to initialize catalog ops when closing catalog

### Why are the changes needed?

Fix: #3673 

### Does this PR introduce _any_ user-facing change?

no

### How was this patch tested?

no
github-actions bot pushed a commit that referenced this issue May 31, 2024
…og (#3672)

### What changes were proposed in this pull request?

avoid to initialize catalog ops when closing catalog

### Why are the changes needed?

Fix: #3673 

### Does this PR introduce _any_ user-facing change?

no

### How was this patch tested?

no
jerryshao added a commit that referenced this issue May 31, 2024
…og (#3679)

### What changes were proposed in this pull request?

avoid to initialize catalog ops when closing catalog

### Why are the changes needed?

Fix: #3673 

### Does this PR introduce _any_ user-facing change?

no

### How was this patch tested?

no

Co-authored-by: mchades <[email protected]>
diqiu50 pushed a commit to diqiu50/gravitino that referenced this issue Jun 13, 2024
… catalog (apache#3672)

### What changes were proposed in this pull request?

avoid to initialize catalog ops when closing catalog

### Why are the changes needed?

Fix: apache#3673 

### Does this PR introduce _any_ user-facing change?

no

### How was this patch tested?

no
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
0.5.1 Release v0.5.1 0.6.0 Release v0.6.0 bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant