What prompted this was when I looked first at the client from the viewpoint of
long running clients in AppServers.
I realized that the current abstraction is weird: You create HTable and trigger
a pretty elaborate process of managing HConnections on demand. Initially an
HConnection could not survive a bounce of the cluster, leaving the AppServers
with the client useless until restarted.
To work around issues with this HConnection management the HTablePool monster
was created. A better and easier abstraction is to connect to your cluster
(i.e. create an HConnection) and then use this established connection to get
HTable objects (HTables are then cheap and predictable as they are only
functioning as a convenient proxy for a table, but do not manage any resources).
-- Lars
From: Solomon Duskis <[email protected]>
To: [email protected]
Sent: Thursday, October 23, 2014 7:28 AM
Subject: Re: Managed Connections and HBase 1.0
Yeah, I'm going to continue to tackle this from the perspective of HBase
code, and will definitely proceed with caution. This is a huge change, and
I'll do my best to
I would think that this changes functionality from the user's perspective.
What will users need to know and do regarding this change once they migrate
to 1.0?
What prompted this change?
On Wed, Oct 22, 2014 at 11:11 PM, Nick Dimiduk <[email protected]> wrote:
> Yes, the concept of connection caching, aka, managed connections are going
> away. See also HBASE-9117. I tried rebasing that monster patch a couple
> weeks back and decided it wasn't worth it. If you're interested in tackling
> this problem, I recommend biting off smaller chunks.
>
> On Wed, Oct 22, 2014 at 6:00 PM, Solomon Duskis <[email protected]> wrote:
>
> > I have a question about managed vs. unmanaged connections in HBase 1.0.
> > The new ConnectionFactory implementation and the Connection interface
> don't
> > seem to include the concept of managed connections for tables. Are
> HTable
> > managed connections going to be deprecated?
> >
> > -Solomon Duskis
> >
>
