[
https://issues.apache.org/jira/browse/HIVE-12170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Shelukhin updated HIVE-12170:
------------------------------------
Description:
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).
was:
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 those
who don't have 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).
> 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
>
>
> 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)
