[
https://issues.apache.org/jira/browse/HIVE-17751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16522635#comment-16522635
]
Alan Gates commented on HIVE-17751:
-----------------------------------
Is this any different from the compactor situation? In both cases we have the
metastore kicking off processes that require Hive's execution engine.
On the compactor we don't have agreement on how to move forward.
[~eugene.koifman] believes we should move the compactor to HS2. I see the
appeal there since HS2 has all the necessary tools. My concern is that this
locks non-Hive users out of writing ACID files (unless there is also a Hive
instance using the metastore). In order to keep the compactor in the metastore
we would have to make the engine that executes the jobs pluggable so that
others could use the compactor if they were willing to implement the necessary
execution logic.
It seems to me after a quick glance that the same applies here. Stats being
updated in the background benefits all engines. We don't want to tie that
functionality only to Hive. But it will require abstracting out execution
logic that Hive already has and others could potentially implement.
I think we should come to agreement on this before we start moving the current
compactor and stats background updater code around.
> Separate HMS Client and HMS server into separate sub-modules
> ------------------------------------------------------------
>
> Key: HIVE-17751
> URL: https://issues.apache.org/jira/browse/HIVE-17751
> Project: Hive
> Issue Type: Sub-task
> Components: Standalone Metastore
> Reporter: Vihang Karajgaonkar
> Assignee: Alexander Kolbasov
> Priority: Major
> Attachments: HIVE-17751.01.patch,
> HIVE-17751.06-standalone-metastore.patch
>
>
> external applications which are interfacing with HMS should ideally only
> include HMSClient library instead of one big library containing server as
> well. We should ideally have a thin client library so that cross version
> support for external applications is easier. We should sub-divide the
> standalone module into possibly 3 modules (one for common classes, one for
> client classes and one for server) or 2 sub-modules (one for client and one
> for server) so that we can generate separate jars for HMS client and server.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
