What is the above Nick Dimiduk? Because we are going to undo caching connections?
Unless I'm mistaken, that's the meaning of "HConnection pooling related APIs". With no way to have a "managed" connection, the user must explicitly create and destroy their own. This warning will notify when this deprecated behavior is invoked.
Might be a bit radical for 0.98 since it is out but since internal, might be ok.
These are invasive yes. See WIP patches WIP.04, WIP.05, WIP.06 in the github branch.
Going by the rule book, there is not be enough deprecation time – given 0.98.0 has shipped.
Yes, that's true.
I think HTablePool has to stay for 1.0 even though broke.
I wish very much to at least get rid of this for 1.0 (even if the connection cache remains). It's difficult to use correctly and HConnection has been around long enough that people are using it mostly, I think. Further, if we introduce the new API as we've discussed with Enis Soztutar, 1.0 will ship with no fewer than 5 ways to acquire a handle on a cluster table (HTablePool#getTable, HTableFactory#createHTableInterface, "managed" HTables via constructor, HConnection#getTable, and whatever our new 1.0 API looks like). Surely we can drop something. The pool and the factory are my preference.
The Connection setup is heavy, right? To ZK, and then to RS. If a Connection per, is there sharing?
As I understand it, yes, it is heavy weight. That why the patch is large, I unwind placed were an implicitly cached connection is (hopefully) retrieved via Configuration and instead explicitly hold an HConnection and thread it through where a Configuration once went. That way, the connection is explicitly shared instead of implicitly via the cache. Easier to reason about, simpler to trace.
Can we get some of the work in at least? The first few items in your list?
I hope we can take it as far as removing use of the connection cache in our internal implementation for 1.0 (through WIP.06). Leave it around for users if we must, though by our rules, we won't be able to drop it until 2.0 at the earliest.