But don't forget you don't have to use pooled tables anymore. You can
create the tables you need on the fly, see "9.3.1.1. Connection Pooling."
IIRC, it's available in the version you're using (but I haven't checked).
Cheers,
Nicolas
On Wed, Apr 10, 2013 at 5:26 PM, Jim the Standing Bear <
stan
I think there is something in the middle that could be done. It was
discussed here a while ago, but without any JIRA created. See thread:
http://mail-archives.apache.org/mod_mbox/hbase-user/201302.mbox/%3CCAKxWWm19OC+dePTK60bMmcecv=7tc+3t4-bq6fdqeppix_e...@mail.gmail.com%3E
If someone can spend s
Hey Varun,
Could you please share the logs and the configuration (hdfs / hbase
settings + cluster description). What's the failure scenario?
>From an HDFS pov, HDFS 3703 does not change the dead node status. But these
node will be given the lowest priority when reading.
Cheers,
Nicolas
On Fri
erver.datanode.DataNode: NameNode
> at ec2-107-20-237-30.compute-1.amazonaws.com/10.168.7.226:8020 calls
>
> recoverBlock(BP-696828882-10.168.7.226-1364886167971:blk_-5723958680970112840_174056,
> targets=[10.156.194.94:50010, 10.156.192.106:50010, 10.156.195.38:50010],
> newGenerationStamp=1
> >> > > WAL block) and the rs logs which got stuch doing the log split.
> Action
> >> > > begins at 2013-04-19 00:27*.
> >> > >
> >> > > Also, the rogue block is 5723958680970112840_174056. Its very
> >> in
gSplitter.getReader(HLogSplitter.java:821)
> >> >---at
> >>
> org.apache.hadoop.hbase.regionserver.wal.HLogSplitter.getReader(HLogSplitter.java:734)
> >> >---at
> >>
> org.apache.hadoop.hbase.regionserver.wal.HLogSplitter.splitLogFile(HLogSplitter.java:381)
> &
You can try Yourkit, they have evaluation licenses. There is one gotcha:
some classes are excluded by default, and this includes org.apache.* . So
you need to change the default config when using it with HBase.
On Thu, May 2, 2013 at 7:54 PM, Bryan Keller wrote:
> I ran one of my regionservers
That's HDFS.
When a file is currently written, the size is not known, as the write is in
progress. So the namenode reports a size of zero (more exactly, it does not
take into account the hdfs block beeing written when it calculates the
size). When you read, you go to the datanode owning the data,
> wrote:
>
> > Thanks Nicolas,
> >
> > When will this file be finalized. Is it time bound? Or it will be always
> > be zero for last one (even if it contains the data)
> >
> > -Original Message-
> > From: Nicolas Liochon [mailto:nkey...@gm
Hello,
Option 1:
We still have some flaky tests. You can benchmark you build against
https://builds.apache.org/job/HBase-TRUNK/ and
https://builds.apache.org/job/hbase-0.95/
You can also use this tool: https://github.com/jeffreyz88/jenkins-tools to
get a review on the last fails:
On 0.95, we have
uld this be a problem? I would try out anyway. Thanks!
>
>
>
>
>
> On Wed, May 29, 2013 at 3:12 PM, Nicolas Liochon
> wrote:
>
> > Hello,
> >
> > Option 1:
> > We still have some flaky tests. You can benchmark you build against
> > https://builds.a
What was your test exactly? You killed -9 a region server but kept the
datanode alive?
Could you detail the queries you were doing?
On Wed, Jun 12, 2013 at 2:10 PM, kiran wrote:
> It is not possible for us to migrate to new version immediately.
>
> @Anoop we purposefully brought down one region
hintaguntla <
> chrajeshbab...@gmail.com> wrote:
>
> > You can configure below to more value to close more regions at a time.
> >
> >
> > hbase.regionserver.executor.closeregion.threads
> > 3
> >
> >
> >
> > On Wed, Jun 1
Scan scan = new Scan(Bytes.toBytes("adidas"), Bytes.toBytes("adidas1"));
>
>
> Our cluster size is 15. The load average when I see in master is 78%...It
> is not that overloaded. but writes are happening in the cluster...
>
> Thanks
> Kiran
>
>
>
&
It could be HBASE-6870?
On Mon, Jul 29, 2013 at 7:37 PM, Jean-Daniel Cryans wrote:
> Can you tell who's doing it? You could enable IPC debug for a few secs
> to see who's coming in with scans.
>
> You could also try to disable pre-fetching, set
> hbase.client.prefetch.limit to 0
>
> Also, is it
Seems to be the same issue as here:
http://stackoverflow.com/questions/16847319/cassandra-on-solaris-10-64-bit-crashing-with-unsafe-getlong
It says it a jvm bug and it seems right.
You may want to try the very last jvm on your platform (it's unlikely to
work), as well as the jdk 1.6 (it could work
Well done, Rajesh!
On Tue, Aug 13, 2013 at 8:44 AM, Anoop John wrote:
> Good to see this Rajesh. Thanks a lot to Huawei HBase team!
>
> -Anoop-
>
> On Tue, Aug 13, 2013 at 11:49 AM, rajeshbabu chintaguntla <
> rajeshbabu.chintagun...@huawei.com> wrote:
>
> > Hi,
> >
> > We have been working on
It's not uncommon to bump these values to something like 5 minutes, for the
exact reason you mention.
The obvious impact is that if the clients don't close the connections the
server will have to keep the resources. It's usually manageable.
Another one is that if the machine running the server dies
It's open source. My personal point of view is that if someone is willing
to spend time on the backport, there should be no issue, if the regression
risk is clearly acceptable & the rolling restart possible. If it's
necessary (i.e. there is no agreement of the risk level), then we could as
well go
There is a comment in this class that is outdated ("Once set, the
parameters that specify a column cannot be changed without deleting the
column and recreating it. If there is data stored in the column, it will be
deleted when the column is deleted."). This is from 2007. I will fix this.
It's poss
27;655
36', IN_MEMORY => 'false', ENCODE_ON_DISK => 'true', BLOCKCACHE =>
'true'}
1 row(s) in 0.0040 seconds
On Mon, Sep 9, 2013 at 10:51 AM, Gaetan Deputier wrote:
> I tried on a simple table using the following commands :
>
> create 't&#
That's linux terminology. 0.95 is a developper release It should not go in
production. When it's ready for production, it will be released as 0.96
0.96 should be ready soon, tests (and fixes are in progress). There is
already a release candidate available: 0.96.RC0.
There should be a new release ca
(redirected user mailing list, dev mailing list in bcc)
Various comments:
- you should not need to add the hadoop jar in your client application pom,
they will come with hbase. But this should not the cause of your issue.
- what does the server say in its logs?
- I'm suprised by this: Client
envi
You won't have this directly. /hbase/rs contains the regionservers that are
online. When a regionserver dies, hbase (or zookeeper if it's a silent
failure) will remove it from this list. (And obviously this is internal to
hbase and could change or not at any time :-) ). But technically you can do
a
Congratulations, Nick!
;-)
On Wed, Sep 11, 2013 at 8:17 AM, Anoop John wrote:
> Congratulations Nick... Welcome...
>
> -Anoop-
>
> On Wed, Sep 11, 2013 at 10:23 AM, Marcos Luis Ortiz Valmaseda <
> marcosluis2...@gmail.com> wrote:
>
> > Congratulations, Nick !!! Keep doing this great work
> >
> My understanding is that HBase requires "durable sync" capabilities of
HDFS (i.e. hflush() hsync()), but does *not* require file append
capabilities.
99.99% true. The remaining 0.01% is an exceptional code path during the
data recovery (as a fall back mechanism to ensure that we can start the
r
Hi,
I haven't seen it mentioned, but if I understand correctly each scan
returns a single row? If so you should use Scan#setSmall to save some rpc
calls.
Cheers,
Nicolas
On Sun, Oct 5, 2014 at 11:28 AM, Qiang Tian wrote:
> when using separate HConnection instance, both its
> RpcClient instan
+1
Le 31 oct. 2014 23:49, "Andrew Purtell" a écrit :
> Based on the positive responses thus far, and unless we see an objection
> between now and then, I plan to resolve HBASE-12397 next week by removing
> support in 0.98 branch for Hadoop 1.0 (but not Hadoop 1.1) in time for
> release 0.98.8.
>
Hi Arul,
It's a pure client exception: it means that the client has not even tried
to send the query to the server, it failed before.
Why the client failed is another question.
I see that the pool size is 7, have you changed the default configuration?
Cheers,
Nicolas
On Tue, Nov 18, 2014 at 7:2
fwiw "CallerDisconnectedException: Aborting call multi" means that:
- the query was under execution on the server
- the client reached its timeout and disconnected
- the server saw that and stopped the execution of the query.
So it's the consequence of a slow execution, not the cause.
It would wor
You should first try with the 'autoflush' boolean on the htable: set it to
false. it buffers the writes for you and does the writes asynchronously. So
all the multithreading / buffering work is done for you.
If you need a synchronisation point (to free the resources on the sending
side), you can ca
It's in local memory. When HBase cannot connect to a server, it puts it
into the "failedServerList" for 2 seconds. This is to avoid having all the
threads going into a potentially long socket timeout. Are you sure that you
can connect from the master to this machine/port?
You can change the time i
It's going to be fairly difficult imho.
What you need to look at is region. Tables are split in regions. Regions
are allocated to region server (i.e. an hbase node). Reads and writes are
directed to the region server owning the region. Regions can move from one
region server to another, that's the
If I understand the issue correctly, restarting the master should solve the
problem.
On Wed, Mar 4, 2015 at 5:55 AM, Ted Yu wrote:
> Please see HBASE-13067 Fix caching of stubs to allow IP address changes of
> restarted remote servers
>
> Cheers
>
> On Tue, Mar 3, 2015 at 8:26 PM, Sandeep L
> w
As Bryan.
Le 5 mars 2015 17:55, "Bryan Beaudreault" a
écrit :
> You should run with a backup master in a production cluster. The failover
> process works very well and will cause no downtime. I've done it literally
> hundreds of times across our multiple production hbase clusters.
>
> Even if y
If the node is dead, the NoRouteToHostException can happen.
This could be a hdfs or hbase bug (or something else).
For how long to you see the NoRouteToHostException exception?
Basically hbase will try to use that node under hdfs discovers that the
node is stale or dead.
With the default hdfs set
You've changed the value of hbase.zookeeper.timeout to 15 minutes? A very
reasonable target is 1 minute before relocating the regions. That's the
default iirc. You can push it to 20s, but then gc-stopping-the-world
becomes more of an issue. 15 minutes is really a lot. The hdfs stale mode
must alway
ionStates:
> Offlined 0e7cc87a4ef6c47a779186f5bf79a01c from {name_of_node_I_took_down}
> ,60020,1426860403261
>
> 2015-03-20 14:32:35,191 INFO org.apache.hadoop.hbase.master.RegionStates:
> Transitioned {25ab6e7b42e36ddaa723d71be5954543 state=OPEN,
> ts=1426860641783, server={
t of from 40 times / 15
> > minutes to something more useful, as for 15 minutes we don't have our
> > regions available, and HDFS have however replication factor 3.
> >
> > Googling, if I figure out what's this I will post it here. Will also
> > appreciate if s
ntent
> > ionally_get_down_by_getting_network_down},60020,1426862900
> > 506-splitting/{node_i_intentionally_get_down_by_gett
> > ing_network_down}%2C60020%2C1426862900506.1427096924508
> > > > after 908210ms
> > > >
> > > > And as you can see f
ld be enough for RegionServer to stop trying to recover from the
> dead node, but it wasn't the case. Also, this whole MTTR article in HBase
> book doesn't work at all with this parameter set to it's default value (15
> minutes).
>
> So I'm still struggling to figur
gt; >
> > Reading the above with interest, thanks for digging in here guys.
> >
> > On Mon, Mar 23, 2015 at 10:13 AM, Nicolas Liochon
> > wrote:
> >
> > > If the node is actually down it's fine. But the node may not be that
> down
> > > (CAP
eck would be the thing that prevents this, correct? I'm surprised it
> didn't help Dejan.
>
> On Mon, Mar 23, 2015 at 11:20 AM, Nicolas Liochon
> wrote:
>
> > @bryan: yes, you can change hbase.lease.recovery.timeout if you changed
> he
> > hdfs settings. But
Actually, double checking the final patch in HDFS-4721, the stale mode is
taken in account. Bryan is right, it's worth checking the namenodes config.
Especially, dfs.namenode.avoid.write.stale.datanode must be set to true on
the namenode.
On Mon, Mar 23, 2015 at 5:08 PM, Nicolas Liochon
as true all the time, together with dfs.namenode.avoid.read.stale.
> > datanode.
> >
> > On Mon, Mar 23, 2015 at 5:29 PM Nicolas Liochon
> wrote:
> >
> >> Actually, double checking the final patch in HDFS-4721, the stale mode
> is
> >> t
Just to make it a little bit more complex, let me put repeat what Nick
already said in this thread:
"However, a detail of our region recovery process
is that a region actually comes online for writes *before* it's available
for reads. That is, it can recover into a state that is
available-for-writ
(removing dev list)
> We observed there is an zxid mismatch on hbase server logs.
This looks like a bug. But the 0.94.15 is quite old now...
For hbase.client.retries.number=3, HBase uses an exponential back-off time,
so setting the #retry to 3 will reduce the hanging time to a few dozen of
seconds
Hi,
Some stuff below:
On Thu, Oct 18, 2012 at 1:30 PM, 张磊 wrote:
> Hi, All
>
> One of the RegionServer of our company’s cluster was crashed. At this
> time, I found:
>
> 1. All the RegionServer stopped handling the requests from the client
> side( requestsPerSecond=0 at the master-statu
Hi,
The schema design is important. There is this entry to look at at least:
http://hbase.apache.org/book.html#rowkey.design
For the config, could you pastebin the hdfs & hbase config files you used?
N.
On Tue, Oct 23, 2012 at 5:48 PM, Nick maillard <
nicolas.maill...@fifty-five.com> wrote:
> H
Thanks, checking the schema itself is still interesting (cf. the link sent)
As well, with 3 machines and a replication factor of 3, all the machines
are used during a write. As HBase writes all entries into a write-ahead-log
for safety, the number of writes is also doubled. So may be your machine i
Hi,
It's ok with a capital 'K'
mvn -PlocalTests -Dtest=TestZoo*K*eeper test
Running org.apache.hadoop.hbase.TestZooKeeper
Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 198.84 sec
;-)
Nicolas
On Tue, Oct 30, 2012 at 5:50 AM, Ted Yu wrote:
> The following command didn't run
Hi Varun,
HDFS-3703 and HDFS-3912 are about this.
The story is not over yet (and there are other stuff like HDFS-3704,
HDFS-3705, HDFS-3706), but it helps by lowering the probability to go to a
dead datanode: hdfs waits 10 minutes before deciding a datanode is dead,
with the jiras mentionned above
Today, at this time of writing, it should be ok: the tests write in a
specific directory, and the ports are dynamic. But it's not without danger:
what if tomorrow someone creates a bug and hardcodes a port already used by
your cluster ? It's unlikely; but it happened in the past. As well, the CPU
&
s with my own user while hbase and hadoop are both running for
> a their own. I don't think there is a risk for the local test to fine
> and write on the local HBase/Hadoop files.
>
> JM
>
> 2012/11/8, Nicolas Liochon :
> > Today, at this time of writing, it should be
Yes, it's not useful to set the master address in the client. I suppose it
was different a long time ago, hence there are some traces on different
documentation.
The master references itself in ZooKeeper. So if the master finds itself to
be "locahost", ZooKeeper will contain "locahost", and the cli
We would detect it and stop properly. It's true even in standalone mode:
one may want to launch a standalone cluster and connects remotely to it.
On Mon, Nov 26, 2012 at 6:38 PM, Stack wrote:
> distributed, write other than localhost to zk?
> St.Ack
>
Hi Mohammad,
Your answer was right, just that specifying the master address is not
necessary (anymore I think). But it does no harm.
Changing the /etc/hosts (as you did) is right too.
Lastly, if the cluster is standalone and accessed locally, having localhost
in ZK will not be an issue. However, i
It's a regression in 3.4.4 (HBASE-6917), fixed in 3.4.5 (HBASE-7159)
Cheers,
Nicolas
On Thu, Nov 29, 2012 at 10:16 AM, Yu Li wrote:
> Dear all,
>
> I checked the Zookeeper site and found the latest stable release is 3.4.5,
> and although there's only 2 bug fixes from zk 3.4.4 to 3.4.5, there'
Theoretically, there is no problem in using HBase 94.x & ZK 3.4.5. If there
is a problem with this config, we should have it as well with HBase 0.96.
On Thu, Nov 29, 2012 at 5:33 PM, Yu Li wrote:
> recently, no wonder I got zk 3.4.3 in my stale pom.xml...
Likely. What's the HBase version btw?
On Fri, Nov 30, 2012 at 6:51 PM, wayne li wrote:
> Found 1 deadlock.
>
> I have checked via a manual client, zookeeper and regionservers is working
> fine. I can getData from znode /hbase/root-region-server.
>
It's not accessible, but it's more or less transparent (latency impact
aside) for the end user: the hbase client will retry the operation.
On Sun, Dec 2, 2012 at 11:10 PM, Jean-Marc Spaggiari <
jean-m...@spaggiari.org> wrote:
> ?
lable because the region server is down for less than 3 minutes,
> right?
>
> Thanks,
>
> JM
>
> 2012/12/2, Nicolas Liochon :
> > It's not accessible, but it's more or less transparent (latency impact
> > aside) for the end user: the hbase client will ret
After looking at the code, it's seems that it's done by the mini zk
cluster: the directory is deleted at startup.
This is because the default mode (non distributed, all threads in a single
process) uses a specific piece of code (this mini* stuff). As it's for
tests, it ensures that there is no rema
: jeudi 13 décembre 2012 13:58
> À : user@hbase.apache.org
> Objet : Re: loss znode
>
>
> Hi Christophe,
>
> What do you mean by " I can not do it "?
>
> Is it giving you an error? You don't know the steps? You don't have the
> rights?
>
&g
port of 3181. ZK was started at port:
> >> 3182.
> >> Aborting as clients (e.g. shell) will not be able to find this ZK
> >> quorum.
> >>
> >> Log file :
> >> 2012-12-13 13:58:35,053 INFO
> >> org.apache.zookeeper.server.NIOServerC
This should help:
http://hbase.apache.org/book/important_configurations.html#bigger.regions
On Mon, Dec 17, 2012 at 9:11 AM, tgh wrote:
>
> Or what about the max size for one region and what about the max
> size of region for one server?
>
HBASE-5718 seems to say it's reproducible only on openjdk.
HBase requires the jdk from Oracle (see
http://hbase.apache.org/book.html#basic.prerequisites).
Issues that occur on other jdk are not rejected, but usually receives a
lower priority. If someone provides a patch, it will be integrated.
On
I think it's safer to use a newer version (0.94): there are a lot of things
around performances & volumes in the 0.92 & 0.94. As well, there are much
more bug fixes releases on the 0.94.
For the number of region, there is no maximum written in stone. Having too
many regions will essentially impact
Hi,
First, check the date/time on both server and check they don't differ;
that's what the error says.
You can configure the max allowed with "hbase.master.maxclockskew", but
it's unlikely to be a good idea: it's always safer, in any distributed
system, to have the servers sharing the same time. n
You don't want the a balancer to move a region to a region server you're
about to close. And a rolling restart is stressful enough on the system;
minimizing any extra noise is safer.
But when a region server dies, its regions are reallocated, whatever the
balancer settings.
On Thu, Dec 27, 2012 at
Hi Jean-Marc,
I'm not aware of any required magic, butI haven't tested the RC.
Have you tried to do a maven clean install -DskipTests?
Nicolas
On Wed, Jan 2, 2013 at 4:10 PM, Jean-Marc Spaggiari wrote:
> Hi,
>
> When I try to run the tests on 0.94.4RC I'm getting "hbase-default.xml
> file see
hbasetest.sh was developed before we had the parallelism by maven surefire.
It's not really maintained anymore (actually it's somewhere in my todo list
to remove it). But for sure there is no magic there :-).
On Wed, Jan 2, 2013 at 4:45 PM, Jean-Marc Spaggiari wrote:
> take a look into hbasete
Hi,
It's actually not implemented (I will update the javadoc for the latest
version)
You can use locateRegion(final byte [] tableName, final byte [] row), and
iterates on all region start keys to get all the regions.
Cheers,
Nicolas
On Wed, Jan 2, 2013 at 5:17 PM, Lyska Anton wrote:
> Hi a
If it works, it's ok: it's not going to give you wrong results. Just that
it adds nothing to a plain mvn test.
So if it worked for you on this patch, then you're done :-).
This should be enough most most cases:
mvn test
If you want to play it safe, you will run all the tests before sending the
pa
>From what I see in 0.94 and in the jira, it should work, there is nothing
fancy there.
moving to dev list btw, user in bcc.
On Wed, Jan 2, 2013 at 6:15 PM, Nicolas Liochon wrote:
> If it works, it's ok: it's not going to give you wrong results. Just that
> it adds nothing
Hi,
It will work, but there is some glue code to write as one is returning one
region given a rowkey, while the not implemented one returns all the
version.
Code written by Lyska seems fine, we could put it in locateRegions (doing
this server side is more efficient)
Nicolas
On Thu, Jan 3, 2013
Yep, I'm ok with that. It will need to be put in the interface (vs. the
implementation class). Would be nice if you could implement the two missing
methods (i.e. public HRegionLocation locateRegion(final byte [] regionName))
On Thu, Jan 3, 2013 at 7:33 PM, Jean-Marc Spaggiari wrote:
> public L
Hi,
IIRC, it's still there on 0.94. 0.96 is not yet released, it's still in
dev, so 0.94 is anyway the version to use. HBASE-6553 contains the patch to
revert if you want to build your own 0.96 version with Avro.
>From the mail archive, the reasons for deprecate it then remote it were:
'HBASE-240
Hi,
>From the logs, it seems you trying to use the non distributed mode:
WARN org.apache.hadoop.hbase.regionserver.HRegionServerCommandLine: Not
starting a distinct region server because hbase.cluster.distributed is false
If it's the case, you don't have to launch a separate zookeeper & region
se
Well, first you need to decide on what you want to do (i.e; distributed or
not) and acts accordingly.
I would recommend trying with not distributed when you start. This means
you have a single process to launch.
not distributed is the default, so if it can't find the configuration files
it will be
Yes, HTable is not thread safe, and using synchronized around them could
work, but would be implementation dependent.
You can have one HTable per request at a reasonable cost since
https://issues.apache.org/jira/browse/HBASE-4805. It's seems to be
available in 0.92 as well.
Cheers,
Nicolas
On M
inimize the synchronization
> granularity?
>
> Thanks so much!
> Bing
>
> On Tue, Feb 5, 2013 at 5:31 AM, Nicolas Liochon wrote:
> > Yes, HTable is not thread safe, and using synchronized around them could
> > work, but would be implementation dependent.
> >
Hi,
Looking at the code, no.
Nicolas
On Tue, Feb 5, 2013 at 9:21 AM, samar kumar wrote:
> Thanks Adrien.
> Sure , but is there any other way without stoping the masters. Anything
> like cleaning the zk. Is there a time-out which cleans the dead rs or max
> count .
> Regards,
> Samar
>
> On 05/
Congrats, Devaraj!
On Thu, Feb 7, 2013 at 2:26 PM, Marcos Ortiz wrote:
> Congratulations, Devaraj.
>
>
> On 02/07/2013 02:20 AM, Lars George wrote:
>
>> Congrats! Welcome aboard.
>>
>> On Feb 7, 2013, at 6:19, Ted Yu wrote:
>>
>> Hi,
>>> We've brought in one new Apache HBase Committer: Devara
i) Yes, or, at least, of often yes.
II) You're right. It's difficult to guess how much it would improve the
performances (there is a lot of caching effect), but using a single scan
could be an interesting optimisation imho.
Nicolas
On Mon, Feb 18, 2013 at 10:57 AM, Varun Sharma wrote:
> Hi,
>
Looking at the code, it seems possible to do this server side within the
multi invocation: we could group the get by region, and do a single scan.
We could also add some heuristics if necessary...
On Tue, Feb 19, 2013 at 9:02 AM, lars hofhansl wrote:
> I should qualify that statement, actually
am wondering if a scan wrapped around a Get with multiple rows would do
> the same ?
>
> Thanks
> Varun
>
> On Tue, Feb 19, 2013 at 12:37 AM, Nicolas Liochon
> wrote:
>
> > Looking at the code, it seems possible to do this server side within the
> > multi
ntify clusters of close row keys in the Gets and issue a Scan for each
> cluster.
>
>
> -- Lars
>
>
>
>
> From: Nicolas Liochon
> To: user
> Sent: Tuesday, February 19, 2013 9:28 AM
> Subject: Re: Optimizing Multi Gets in hb
As well, an advantage of going only to the servers needed is the famous
MTTR: there are a less chance to go to a dead server or to a region that
just moved.
On Tue, Feb 19, 2013 at 7:42 PM, Nicolas Liochon wrote:
> Interesting, in the client we're doing a group by location the multig
Welcome, Sergey!
On Sat, Feb 23, 2013 at 2:47 AM, Marcos Ortiz wrote:
> Congratulations, Sergey.
>
>
> On 02/22/2013 04:39 PM, Ted Yu wrote:
>
>> Hi,
>> Sergey has 51 issues under his name:
>> *
>> https://issues.apache.org/**jira/issues/?jql=project%20%**
>> 3D%20HBASE%20AND%20assignee%**20%3D
Yes, decommissioning the regionserver does not mean decommissioning the
datanode.
Here, if I understand well your first step, you migrated the regions to
other regions servers. Physically, the data was still on the previous
machine, with the hdfs datanode. It's not used anymore for writes if all
ot
Congrats, Anoop!
On Mon, Mar 11, 2013 at 5:35 AM, rajeshbabu chintaguntla <
rajeshbabu.chintagun...@huawei.com> wrote:
> Contratulations Anoop!
>
>
> From: Anoop Sam John [anoo...@huawei.com]
> Sent: Monday, March 11, 2013 9:00 AM
> To: user@hbase.apache.
The read path is much more complex than the write one, so the response time
has much more variance.
The gap is so wide here that I would bet on Ted's or Stack's points, but
here are a few other sources of variance:
- hbase cache: as Anoop said, may be the data is already in the hbase cache
(setCach
It's hbase.regionserver.metahandler.count. Not sure it causes the issue
you're facing, thought. What's your HBase version?
On Tue, Dec 10, 2013 at 1:21 PM, Federico Gaule wrote:
> There is another set of handler we haven't customized "PRI IPC" (priority
> ?). What are those handlers used for? W
It was written to be generic, but limited to 'put' to maintain the backward
compatibility.
Some 'Row' do not implement 'heapSize', so we have a limitation for some
types for the moment (we need the objects to implement heapSize as we need
to know how when it's time to flush the buffer). This can be
Hi,
It's fixed in HBase 0.96 (by HBASE-9667).
Cheers,
Nicolas
On Mon, Dec 16, 2013 at 11:01 AM, Kristoffer Sjögren wrote:
> Hi
>
> At the moment HFileWriterV2.close breaks at startup when using Guava 15.
> This is not a client problem - it happens because we start a master node to
> do integr
That means more or less backporting the patch to the 0.94, no?
It should work imho.
On Mon, Dec 16, 2013 at 3:16 PM, Kristoffer Sjögren wrote:
> Thanks! But we cant really upgrade to HBase 0.96 right now, but we need to
> go to Guava 15 :-(
>
> I was thinking of overriding the classes fixed in
It's very strange that you don't see a perf improvement when you increase
the number of nodes.
Nothing in what you've done change the performances at the end?
You may want to check:
- the number of regions for this table. Are all the region server busy? Do
you have some split on the table?
- How
It's hbase-client
On Tue, Jan 28, 2014 at 4:36 PM, shapoor wrote:
> To use the new hbase 0.96.1-hadoop2 for a client which dependency should I
> give in my pom.xml ?
>
> I have tried it for example with hbase-it and I get the following
> Exception:
>
>
> 14/01/28 16:30:18 INFO zookeeper.ClientC
That's "standard", even if it's a behavior change compared to 0.94.
It means you're sending puts faster that the server can write.
In such situation, in 0.94, the operation was paused server side. In 0.96,
HBase sends an exception back to the client, and it's up to it to retry
(and it does retry).
1 - 100 of 109 matches
Mail list logo
