[
https://issues.apache.org/jira/browse/HIVE-12170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14959447#comment-14959447
]
Alan Gates commented on HIVE-12170:
-----------------------------------
Here's the motivation and what I was trying to achieve:
* Each thread in HiveMetaStore will have an instance of RawStore, hence of
HBaseStore and HBaseReadWrite
* Each instance needs a copy of the config file, but they should all have the
same copy. Thus the attempt to set it up front with a static call.
* Not all places that need an instance of HBaseReadWrite will have a reference
on hand nor will they have the proper config file. Thus they need to be able
to get the instance without the config file, and they need to get the right
instance for the thread they are running in. Hence the calls to getInstance
with no config and the reference being threadlocal.
So first, a question. Why are we seeing different threads have different
config files? I certainly didn't expect that. Is there a valid reason for it?
I've attached a proposed patch that deals with this by moving getInstance(conf)
to setConf(conf) and only having getInstance(). Does this look reasonable?
> normalize HBase metastore connection configuration
> --------------------------------------------------
>
> Key: HIVE-12170
> URL: https://issues.apache.org/jira/browse/HIVE-12170
> Project: Hive
> Issue Type: Bug
> Reporter: Sergey Shelukhin
> Priority: Blocker
> Fix For: 2.0.0
>
> Attachments: HIVE-12170.patch
>
>
> Right now there are two ways to get HBaseReadWrite instance in metastore.
> Both get a threadlocal instance (is there a good reason for that?).
> 1) One is w/o conf and only works if someone called the (2) before, from any
> thread.
> 2) The other blindly sets a static conf and then gets an instance with that
> conf, or if someone already happened to call (1) or (2) from this thread, it
> returns the existing instance with whatever conf was set before (but still
> resets the current conf to new conf).
> This doesn't make sense even in an already-thread-safe case (like linear
> CLI-based tests), and can easily lead to bugs as described; the config
> propagation logic is not good (example - HIVE-12167); some calls just reset
> config blindly, so there's no point in setting staticConf, other than for the
> callers of method (1) above who don't have a conf and would rely on the
> static (which is bad design).
> Having connections with different configs reliably in not possible, and
> multi-threaded cases would also break - you could even set conf, have it
> reset and get instance with somebody else's conf.
> Static should definitely be removed, maybe threadlocal too (HConnection is
> thread-safe).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
