Re: Why do I get ServiceException?

[Jerry He]

ServiceException  simply means your service call failed for some reason.
For example, the service could not be found on the region server side
because the coprocessor was not registered correctly.
Or the protobuf message / parameter was missing some required field.

Do you see more detailed root cause or message out of the ServiceException?
I guess not.It does make the debug more frustrating.


Jerry

On Tue, May 30, 2017 at 8:06 AM, Ted Yu  wrote:

> Your code snippet is formatted in a strange way.
> Can you pastebin:
>
> code snippet copied from Eclipse (or text editor of your choice)
> complete stack trace for the ServiceException
>
> Which version of hbase are you using ?
>
> Was there any other protobuf jar in the classpath ?
>
> Cheers
>
> On Sun, May 28, 2017 at 10:01 AM, Cheyenne Forbes <
> cheyenne.osanu.for...@gmail.com> wrote:
>
> > I'm getting *com.google.protobuf.ServiceException *when I try:
> >
> >
> >
> >
> >
> >
> >
> > *Configuration conf = HBaseConfiguration.create();
> > try{Connection connection =
> > ConnectionFactory.createConnection(conf);Table table =
> > connection.getTable(TableName.valueOf(Bytes.toBytes( "users" )));
> > MyPB.TestRequest request = *
> >
> >
> >
> > *MyPB.TestRequest.newBuilder().setId("test_id").build();
> > CoprocessorRpcChannel channel =
> > table.coprocessorService(Bytes.toBytes("test_id"));
> > **MyPB.TestService.BlockingInterface
> > service = *
> >
> >
> > *MyPB.TestService.newBlockingStub(channel);
> LOG.warning("avapnoAVO
> > 9");**MyPB.TestResponse response =
> > service.getTestRes(null, request);*
> >
> > Regards,
> >
> > Cheyenne O. Forbes
> >
>

Re: is manually triggered major-compaction forcing a memstore flush

[Enis Söztutar]

Major compaction will not trigger flush. You have to issue that manually.
BTW, you can look at the settings related to "cache on flush" so that when
the flusher writes the files, the blocks can go directly to the block
cache.

Enis

On Mon, May 29, 2017 at 7:45 PM, Eric Owhadi  wrote:

> Hi Hbaseers,
> I am working on a project were we are preparing data on a daily basis, and
> then have it in a form fast to read.
> So I am considering moving the data away from mem-store down to block
> cache.
> So I need to flush and major compact. But I was wondering if I need to
> issue both commands, or if manually triggered major compaction include a
> silent flush before doing the actual major compaction?
> Thanks in advance for the help,
> Eric Owhadi
>

Re: What is Dead Region Servers and how to clear them up?

[jeff saremi]

wonderful! thanks


From: Yu Li 
Sent: Tuesday, May 30, 2017 4:33:59 AM
To: jeff saremi
Cc: d...@hbase.apache.org; hbase-user
Subject: Re: What is Dead Region Servers and how to clear them up?

Thanks for the confirmation Jeff, have opened 
HBASE-18131 for this, FYI.

Best Regards,
Yu

On 29 May 2017 at 03:48, jeff saremi 
> wrote:

Yes Yu. What you're suggesting would work for us too and would still be 
appreciated.

thanks a lot

jeff


From: Yu Li >
Sent: Sunday, May 28, 2017 10:13:38 AM
To: jeff saremi
Cc: d...@hbase.apache.org; hbase-user

Subject: Re: What is Dead Region Servers and how to clear them up?

Thanks for the additional information Jeff, interesting scenario.

Let me re-explain: dead server means on this node (or container, in your case) 
there was a regionserver process once but not now. This doesn't indicate the 
current health state of the cluster, but only tells the fact and alarm operator 
to give a check on those nodes/containers to see what problem cause them dead. 
But I admit that these might cause confusion.

And as I proposed in previous mail, I think in the Yarn/Mesos deployment 
scenario we need to supply a command to clear those dead servers. To be more 
specified, after all the actions, no matter automatic ones like WAL split and 
zk clearance, or the manual ones like hbck -repair, as long as we're sure we 
don't need to care about those dead servers any more, we could remove them from 
master UI. If this satisfies what you desire, I could open a JIRA and get the 
work done (smile).

Let me know your thoughts, thanks.

Best Regards,
Yu

On 28 May 2017 at 23:26, jeff saremi 
> wrote:

I think more and more deployments are being made dynamic using Yarn and Mesos. 
Going back to a fixed set of servers is not going to eliminate the problem i'm 
talking about. Making assumptions that the region servers come back on the same 
node is too optimistic.

Let me try this a different way to see if I can make my point:

- A cluster is either healthy or not healthy.

- If the cluster is unhealthy, then it can be made healthy using either 
external tools (hbck) or the internal agreement of master-regionserver. If this 
is not achievable, then the cluster must be discarded.

- The cluster is now healthy, meaning that no information should be lingering 
on such as dead server, dead regions, or whatever anywhere in the system. And 
moreover no such information must ever be brought up to the attention of the 
administrators of the cluster.

- If there is such information still hiding in some place in the system, then 
it only means that the mechansim (hbck or hbase itself) that made the system 
healthy did not complete its job in cleaning up what is needed to be cleaned up




From: Ted Yu >
Sent: Saturday, May 27, 2017 1:54:50 PM

To: d...@hbase.apache.org
Cc: Hbase-User; Yu Li
Subject: Re: What is Dead Region Servers and how to clear them up?

The involvement of Yarn can explain why you observed relatively more dead
servers (compared to traditional deployment).

Suppose in first run, Yarn allocates containers for region servers on a set
of nodes. Subsequently, Yarn may choose nodes (for the same number of
servers) which are not exactly the same nodes in the previous run.

What Yu Li described as restarting server is on the same node where the
server was running previously.

Cheers

On Sat, May 27, 2017 at 11:59 AM, jeff saremi 
>
wrote:

> Yes. we don't have fixed servers with the exceptions of ZK machines.
>
> We have 3 yarn jobs one for each of master, region, and thrift servers
> each launched separately with different number of nodes. I hope that's not
> what is causing problems.
>
> 
> From: Ted Yu >
> Sent: Saturday, May 27, 2017 11:27:36 AM
> To: d...@hbase.apache.org
> Cc: Hbase-User; Yu Li
> Subject: Re: What is Dead Region Servers and how to clear them up?
>
> Jeff:
> bq. We run our cluster on Yarn and upon restarting jobs in Yarn
>
> Can you clarify a bit more - are you running hbase processes inside Yarn
> container ?
>
> Cheers
>
> On Sat, May 27, 2017 at 10:58 AM, jeff saremi 
> >
> wrote:
>
> > Thanks @Yu Li
> >
> > You are absolutely correct. Dead RS's will happen regardless. My issue
> > with this is more "psychological". If I have done everything needed to be
> > done to ensure that RSs are running fine and regions are 

Re: region files

[Josh Elser]

The assumption is that one of those three copies of the HDFS block 
comprising your HFiles are stored on the local datanode.


That is what the major compaction process guarantee.

On 5/26/17 9:59 AM, Rajeshkumar J wrote:

I have seen the code in that while creating input split they are also
sending region info with that splits. Is there any reason for that as all
the hfiles are not going to be in that server

On Fri, May 26, 2017 at 7:06 PM, Ted Yu  wrote:


Consider running major compaction which restores data locality.

Thanks


On May 26, 2017, at 6:08 AM, Rajeshkumar J 

wrote:


Thanks Ted. If data blocks of the hfile may not be on the same node as

the

region server then how data locality is achieved when mapreduce is run

over

hbase tables




On Fri, May 26, 2017 at 6:15 PM, Ted Yu  wrote:

The hfiles of a region are stored on hdfs. By default, hdfs has

replication

factor of 3.
If you're not using read replica feature, any single region is served by
one region server (however the data blocks of the hfile may not be on

the

same node as the region server).

Cheers

On Thu, May 25, 2017 at 11:45 PM, Rajeshkumar J <
rajeshkumarit8...@gmail.com

wrote:



Hi,

   we have region max file size as 10 GB. Whether the hfiles of a region
exists in same region server or will it be distributed?

Thanks

List of gets performance

[Abhishek Agarwal]

I need to perform a list of gets on HBase. All random row keys.
Currently, the list size can be around 10 row keys.
But with time, this will grow.

Performance impact? Can I improve?

Hbase shell formatting scan to a particular primitive data

[Eko Susilo]

Hi,

I am currently using hbase 1.2.0-cdh5.7.0 and i am performing scan and want
to show the fields in appropriate format using the following syntax
scan 'table', {COLUMNS =>
['cf:qualifier:c(org.apache.hadoop.hbase.util.Bytes).toDouble']}

But it still shows the result in the binary text format

However, if i try to perform get operation using the similar command, the
shell converts the binary text into appropriate format.
Is there configuration missing? Or do i need to import something?

 get 'table', 'rowkey','cf:qualifier:toDouble'

-- 
Best Regards,
Eko Susilo

Re: custom input split

[Yu Li]

Please check org.apache.hadoop.hbase.mapreduce.TableInputFormat

Best Regards,
Yu

On 30 May 2017 at 19:18, Rajeshkumar J  wrote:

> Hi,
>
>Can anyone point me the custom input split for hbase mapreduce example?
>
> Thanks
>

Re: What is Dead Region Servers and how to clear them up?

[Yu Li]

Thanks for the confirmation Jeff, have opened HBASE-18131
 for this, FYI.

Best Regards,
Yu

On 29 May 2017 at 03:48, jeff saremi  wrote:

> Yes Yu. What you're suggesting would work for us too and would still be
> appreciated.
>
> thanks a lot
>
> jeff
> --
> *From:* Yu Li 
> *Sent:* Sunday, May 28, 2017 10:13:38 AM
> *To:* jeff saremi
> *Cc:* d...@hbase.apache.org; hbase-user
>
> *Subject:* Re: What is Dead Region Servers and how to clear them up?
>
> Thanks for the additional information Jeff, interesting scenario.
>
> Let me re-explain: dead server means on this node (or container, in your
> case) there was a regionserver process once but not now. This doesn't
> indicate the current health state of the cluster, but only tells the fact
> and alarm operator to give a check on those nodes/containers to see what
> problem cause them dead. But I admit that these might cause confusion.
>
> And as I proposed in previous mail, I think in the Yarn/Mesos deployment
> scenario we need to supply a command to clear those dead servers. To be
> more specified, after all the actions, no matter automatic ones like WAL
> split and zk clearance, or the manual ones like hbck -repair, as long as
> we're sure we don't need to care about those dead servers any more, we
> could remove them from master UI. If this satisfies what you desire, I
> could open a JIRA and get the work done (smile).
>
> Let me know your thoughts, thanks.
>
> Best Regards,
> Yu
>
> On 28 May 2017 at 23:26, jeff saremi  wrote:
>
>> I think more and more deployments are being made dynamic using Yarn and
>> Mesos. Going back to a fixed set of servers is not going to eliminate the
>> problem i'm talking about. Making assumptions that the region servers come
>> back on the same node is too optimistic.
>>
>> Let me try this a different way to see if I can make my point:
>>
>> - A cluster is either healthy or not healthy.
>>
>> - If the cluster is unhealthy, then it can be made healthy using either
>> external tools (hbck) or the internal agreement of master-regionserver. If
>> this is not achievable, then the cluster must be discarded.
>>
>> - The cluster is now healthy, meaning that no information should be
>> lingering on such as dead server, dead regions, or whatever anywhere in the
>> system. And moreover no such information must ever be brought up to the
>> attention of the administrators of the cluster.
>>
>> - If there is such information still hiding in some place in the system,
>> then it only means that the mechansim (hbck or hbase itself) that made the
>> system healthy did not complete its job in cleaning up what is needed to be
>> cleaned up
>>
>>
>>
>> --
>> *From:* Ted Yu 
>> *Sent:* Saturday, May 27, 2017 1:54:50 PM
>>
>> *To:* d...@hbase.apache.org
>> *Cc:* Hbase-User; Yu Li
>> *Subject:* Re: What is Dead Region Servers and how to clear them up?
>>
>> The involvement of Yarn can explain why you observed relatively more dead
>> servers (compared to traditional deployment).
>>
>> Suppose in first run, Yarn allocates containers for region servers on a
>> set
>> of nodes. Subsequently, Yarn may choose nodes (for the same number of
>> servers) which are not exactly the same nodes in the previous run.
>>
>> What Yu Li described as restarting server is on the same node where the
>> server was running previously.
>>
>> Cheers
>>
>> On Sat, May 27, 2017 at 11:59 AM, jeff saremi 
>> wrote:
>>
>> > Yes. we don't have fixed servers with the exceptions of ZK machines.
>> >
>> > We have 3 yarn jobs one for each of master, region, and thrift servers
>> > each launched separately with different number of nodes. I hope that's
>> not
>> > what is causing problems.
>> >
>> > 
>> > From: Ted Yu 
>> > Sent: Saturday, May 27, 2017 11:27:36 AM
>> > To: d...@hbase.apache.org
>> > Cc: Hbase-User; Yu Li
>> > Subject: Re: What is Dead Region Servers and how to clear them up?
>> >
>> > Jeff:
>> > bq. We run our cluster on Yarn and upon restarting jobs in Yarn
>> >
>> > Can you clarify a bit more - are you running hbase processes inside Yarn
>> > container ?
>> >
>> > Cheers
>> >
>> > On Sat, May 27, 2017 at 10:58 AM, jeff saremi 
>> > wrote:
>> >
>> > > Thanks @Yu Li>
>> > >
>> > > You are absolutely correct. Dead RS's will happen regardless. My issue
>> > > with this is more "psychological". If I have done everything needed
>> to be
>> > > done to ensure that RSs are running fine and regions are assigned and
>> > such
>> > > and hbck reports are consistent then how is this list of dead region
>> > > servers helping me? other than causing anxiety?
>> > > We run our cluster on Yarn and upon restarting jobs in Yarn we get a
>> lot
>> > > 

custom input split

[Rajeshkumar J]

Hi,

   Can anyone point me the custom input split for hbase mapreduce example?

Thanks