hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Birdsall <dave.birds...@esgyn.com>
Subject RE: EndpointCoprocessors with multi-region access
Date Mon, 24 Jul 2017 18:40:16 GMT

I think I understand the answer.

My question was based on incorrect premises. (You can tell I am new to this.)

The CoprocesserService() method will send requests to all region servers serving regions within
a given key range. So each coprocessor instance is handling just one region. I suppose one
could write badly behaved code in a coprocessor instance that does cross servers, but the
natural architecture of an EndPoint coprocessor is to work on one region locally.

The client code that calls CoprocessorService is responsible for processing the set of responses
from each region server that was called.

So in my example, some client side code has to loop through these, adding together the results
from each response.



From: Dave Birdsall
Sent: Monday, July 24, 2017 9:30 AM
To: user@hbase.apache.org
Subject: EndpointCoprocessors with multi-region access


I have a basic question about Endpoint coprocessors.

Suppose I want to write a coprocessor that returns the total number of memstore bytes used
by a table.

I can write code that loops through all the regions, asking their region servers to tell me
the memstore bytes for each given region, and then add them all up.

Such code, of course, will have a RegionServer talking to other RegionServers in the cluster.

Is there any problem with this? For example, when a RegionServer does an RPC to another RegionServer,
does that tie up a thread in the calling RegionServer? And if so, and if my coprocessor is
popular, might I get deadlocks or thread exhaustion errors if multiple RegionServers run my

The more general architectural question is, should an EndPoint coprocessor limit itself to
the regions that are on its own RegionServer? Or does HBase possess appropriate layers to
robustly manage prolific cross-server traffic?



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message