I agree that more documentation would be better. However,
> Yet, there are some applications which require a faster time out than
> others. So, you tune some of the timers to have a fast fail, and you end up
> causing unintended problems for others.
>
> The simplest solution is to use threads in you client app. (Of course this
> assumes that you’re capable of writing clean multi-threaded code and I
> don’t want to assume anything.)
>
> Remember that HBase is a shared resource. So you need to consider the
> whole at the same time you consider the needs of one.
>
>
This is not really true, it assumes a very naive configuration solution in
which all processes are configured the same. The default configs come from
xml files, but are easily customized. Consider:
Application A:
Configuration conf = HBaseConfiguration.create();
conf.setInt("hbase.rpc.timeout", 8000);
// Operations on table have a timeout of 8s
Connection conn = ConnectionFactory.createConnection(conf);
conn.getTable("foo");
Application B:
// Operations on this table use default timeout
Connection conn =
ConnectionFactory.createConnection(HBaseConfiguration.create());
conn.getTable("foo");
// Operations on this table use a very short timeout of 500ms
Configuration conf = HBaseConfiguration.create();
conf.setInt("hbase.rpc.timeout", 500);
Connection shortConn = ConnectionFactory.createConnection(conf);
short
shortConn.getTable("foo");
Applications A and B are configured with different timeouts. Further,
Application B has two separate table connections, each with a different
timeout.
The values are hardcoded above, but could easily be made configurable. The
simplest of solutions uses System.getProperty(), so you can pass
-Dmy.custom.timeout=500. More complex solutions can utilize the various
open source live configuration solutions. Such as netflix archaius, or
hubspot's live-config -- both available on github.
Of course there can be unintended consequences if an application suddenly
> starts to drop connections before a result or timeout occurs too. ;-)
>
>
> > On Jun 16, 2015, at 12:13 AM, lars hofhansl <la...@apache.org> wrote:
> >
> > Please always tell us which version of HBase you are using. We have
> fixed a lot of issues in this area over time.Here's an _old_ blog post I
> wrote about this:
> http://hadoop-hbase.blogspot.com/2012/09/hbase-client-timeouts.html
> >
> > Using yet more threads to monitor timeouts of another thread is a bad
> idea, especially when the timeout is configurable in the first place.
> >
> > -- Lars
> > From: mukund murrali <mukundmurra...@gmail.com>
> > To: user@hbase.apache.org
> > Sent: Sunday, June 14, 2015 10:22 PM
> > Subject: Re: How to make the client fast fail
> >
> > It would be great if there is a single timeout configuration from the
> > client end. All other parameters should fine tune based on that one
> > parameter. We have modified simple based on trail basis to suit our need.
> > Also not sure what side effect it would cause configuring those
> parameters.
> >
> >
> >
> > On Mon, Jun 15, 2015 at 10:38 AM, <hariharan_sethura...@dell.com> wrote:
> >
> >> We are also interested on the solution for this. With
> >> hbase.client.retries.number = 7 and client.pause=400ms, it came down to
> >> ~9mins (from 20 mins). Now we are thinking the 9mins is also a big
> number.
> >>
> >> Thanks,
> >> Hari
> >>
> >> -----Original Message-----
> >> From: PRANEESH KUMAR [mailto:praneesh.san...@gmail.com]
> >> Sent: Monday, June 15, 2015 10:33 AM
> >> To: user@hbase.apache.org
> >> Subject: Re: How to make the client fast fail
> >>
> >> Hi Michael,
> >>
> >> We can have a monitoring thread and interrupt the hbase client thread
> >> after time out instead of doing this I want the timeout or some
> exception
> >> to be thrown from the HBase client itself.
> >>
> >> On Thu, Jun 11, 2015 at 5:16 AM, Michael Segel
> >> wrote:
> >>
> >>> threads?
> >>>
> >>> So that regardless of your hadoop settings, if you want something
> >>> faster, you can use one thread for a timer and then the request is in
> >>> another. So if you hit your timeout before you get a response, you can
> >> stop your thread.
> >>> (YMMV depending on side effects... )
> >>>
> >>>> On Jun 10, 2015, at 12:55 AM, PRANEESH KUMAR
> >>>>
> >>> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> I have got the Connection object with default configuration, if the
> >>>> zookeeper or HMaster or Region server is down, the client didn't
> >>>> fast
> >>> fail
> >>>> and it took almost 20 mins to thrown an error.
> >>>>
> >>>> What is the best configuration to make the client fast fail.
> >>>>
> >>>> Also what is significance of changing the following parameters.
> >>>>
> >>>> hbase.client.retries.number
> >>>> zookeeper.recovery.retry
> >>>> zookeeper.session.timeout
> >>>> zookeeper.recovery.retry.intervalmill
> >>>> hbase.rpc.timeout
> >>>>
> >>>> Regards,
> >>>> Praneesh
> >>>
> >>>
> >>
> >
> >
>
>
