[
https://issues.apache.org/jira/browse/IMPALA-9824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17134469#comment-17134469
]
Vihang Karajgaonkar commented on IMPALA-9824:
---------------------------------------------
Spend sometime on this and almost made it to work. We can still make it work
but it made me think that we are trying to solve 2 conflicting requirements.
Our FE unit tests spin up their own CatalogServiceCatalog instances (see
CatalogServiceTestCatalog for example). Testing can become flaky if we make
MetastoreClientPool a singleton since all the FE tests run within a single
process and that would mean they will share the MetastoreClientPool. We
currently rely on Catalog#close() call in the tests to shutdown the pool. This
works ok for most of the tests except the ones which rely on
{{createTransientTestCatalog}} which uses a EmbeddedHMS service. Currently
MetastoreClientPool should have one to one mapping with the Catalog instances.
The MetastoreClientPool in {{DirectMetaProvider}} should ideally never get
instantiated after we fix IMPALA-9375. We should only have either
CatalogMetaProvider or DirectMetaProvider running but not both.
I am now inclined to abandon this patch and close this JIRA as "wont fix".
[~stakiar] [~stigahuang] any thoughts?
> MetastoreClientPool should be singleton
> ---------------------------------------
>
> Key: IMPALA-9824
> URL: https://issues.apache.org/jira/browse/IMPALA-9824
> Project: IMPALA
> Issue Type: Improvement
> Components: Catalog
> Reporter: Vihang Karajgaonkar
> Assignee: Vihang Karajgaonkar
> Priority: Minor
>
> Currently, the MetastoreClientPool is instantiated at multiple places in the
> code and it would be good to refactor the code to make it a singleton. Each
> MetastoreClientPool creates multiple clients to HMS and unnecessary creation
> of multiple pools could cause problems on HMS side.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]