[
https://issues.apache.org/jira/browse/HIVE-11388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15001077#comment-15001077
]
Alan Gates commented on HIVE-11388:
-----------------------------------
Avoiding ZK is a major bonus. I'm wondering if your first proposal of having
another state would be better. Depending on the cleaner being on the same host
seems like it has some issues:
# How do we deal with the case where the cleaner thread on a metastore dies?
The workers will keep compacting but no one will be cleaning up.
# How do we detect orphaned compactions in the waiting for cleaning state?
Minus something like ZK it's not immediately obvious to me how to figure out
that a given metastore instance died or was shut down and that another cleaner
should step in and take over. You could wait a day or something, but even then
you'd have to manage determining who stepped in. Basically I think you'll have
to have some form of coordination and doing it in the database seems like the
best method.
> there should only be 1 Initiator for compactions per Hive installation
> ----------------------------------------------------------------------
>
> Key: HIVE-11388
> URL: https://issues.apache.org/jira/browse/HIVE-11388
> Project: Hive
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 1.0.0
> Reporter: Eugene Koifman
> Assignee: Eugene Koifman
>
> org.apache.hadoop.hive.ql.txn.compactor.Initiator is a thread that runs
> inside the metastore service to manage compactions of ACID tables. There
> should be exactly 1 instance of this thread (even with multiple Thrift
> services).
> This is documented in
> https://cwiki.apache.org/confluence/display/Hive/Hive+Transactions#HiveTransactions-Configuration
> but not enforced.
> Should add enforcement, since more than 1 Initiator could cause concurrent
> attempts to compact the same table/partition - which will not work.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
