Yes and, also, situations where, for example, infrastructure problems and other factors impact query performance.
-----Original Message----- From: Jean-Marc Spaggiari [mailto:[email protected]] Sent: Friday, March 07, 2014 10:23 AM To: user Subject: Re: API to view active, completed, and failed HBase queries Hi Gunnar, A get or a put in HBase is supposed to be VERY fast. Like, few milliseconds. So I'm not sure to get "being able to kill queries that are running too long". What is running so long? Are you talk about other external requests run by other tools against HBase? JM 2014-03-07 11:26 GMT-05:00 Tapper, Gunnar <[email protected]>: > Hi Jean-Marc, > > Yes, I already have the RPC information but I want to actually view > and control queries including being able to kill queries that are > running too long or taking too many resources. > > A fail is usually a query that started (passed syntax check and > authorization checks) but couldn't complete for whatever reason. A > queued query is a query that has to wait for a resource before it's allowed > to run. > > Thanks, > > Gunnar > > The person that says it cannot be done should not interrupt the person > doing it. > > -----Original Message----- > From: Jean-Marc Spaggiari [mailto:[email protected]] > Sent: Friday, March 07, 2014 9:17 AM > To: user > Subject: Re: API to view active, completed, and failed HBase queries > > Hi Gunnar, > > You can look at the metrics to see the RPC queues, that will give you > an idea of the active and completed requests. But I don't think there > is anything about "failed". > > Also, failed might have multiple sense. A get with no results, is it a > fail? A get against an unknown table? Or it's only when the RPC did > not reach the server? etc. > > JM > > > 2014-03-07 11:10 GMT-05:00 Tapper, Gunnar <[email protected]>: > > > Hi, > > > > Is there an API that allows me to view active, completed, queued, > > and failed HBase queries beyond setting slow-query log to a low > > number and parsing the log files? > > > > Thanks, > > > > Gunnar > > > > The person that says it cannot be done should not interrupt the > > person doing it. > > > > >
