Details
-
Bug
-
Status: Closed
-
Blocker
-
Resolution: Fixed
-
None
-
None
-
None
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).
Attachments
Attachments
Issue Links
- is duplicated by
-
HIVE-12167 HBase metastore causes massive number of ZK exceptions in MiniTez tests
- Resolved
- is related to
-
HIVE-12167 HBase metastore causes massive number of ZK exceptions in MiniTez tests
- Resolved