ryan rawson created HBASE-12941:
---
Summary: CompactionRequestor - a private interface class with no
users
Key: HBASE-12941
URL: https://issues.apache.org/jira/browse/HBASE-12941
Project: HBase
I'm checking to see if our marketing and web team can help. The
primary requirement is going to be ditching the mvn:site from the
front page. reskinning it might not be so easy.
-ryan
On Thu, Dec 4, 2014 at 9:52 AM, lars hofhansl la...@apache.org wrote:
+1
I just came across one of the
Hi all,
The next HBase user group meeting is on November the 20th. We need a
few more presenters still!
Please send me your proposals - summary and outline of your talk!
Thanks!
-ryan
ryan rawson created HBASE-12260:
---
Summary: MasterServices - remove from coprocessor API (Discuss)
Key: HBASE-12260
URL: https://issues.apache.org/jira/browse/HBASE-12260
Project: HBase
Issue
ryan rawson created HBASE-12192:
---
Summary: Remove EventHandlerListener
Key: HBASE-12192
URL: https://issues.apache.org/jira/browse/HBASE-12192
Project: HBase
Issue Type: Bug
, Ryan Rawson ryano...@gmail.com wrote:
This is a cool idea, I'd like to contribute, but I'll need coverage
since I cannot guarantee my time (since it doesnt belong to me
anyways).
What do you need Ryan?
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting
This is a cool idea, I'd like to contribute, but I'll need coverage
since I cannot guarantee my time (since it doesnt belong to me
anyways).
Hey folks,
I built something out here at DTS, and I wanted to get feedback to see
if it was interesting for anyone else... I built a no-dependency
GraphiteReportingContext module that allows hadoop metrics to be
exported to a graphite service. We've been using it here for a month
and it works
I've used mockito a few times, and it's great... but it can make your
tests very brittle. It can also be hard to successfully use if the
code is complex. For example I had a class that took an HBaseAdmin,
and i mocked out the few calls it used. Then when I needed to access
Configuration, things
On Fri, Jun 29, 2012 at 5:04 PM, Todd Lipcon t...@cloudera.com wrote:
A few inline notes below:
On Fri, Jun 29, 2012 at 4:42 PM, Elliott Clark ecl...@stumbleupon.comwrote:
I just posted a pretty early skeleton(
https://issues.apache.org/jira/browse/HBASE-2182) on what I think a netty
based
Good job Andrew. Don't forget to expense it - problem solved!
-ryan
On Sat, Oct 1, 2011 at 6:26 PM, Ted Dunning tdunn...@maprtech.com wrote:
I can get some sponsorship going on my end as well.
On Sun, Oct 2, 2011 at 12:09 AM, Ted Yu yuzhih...@gmail.com wrote:
I agree. We should share the
an if-statement to determine the class of the other HCell, and
choose the fastest byte comparison method behind the scenes.
I need to look into the KeyValue scanner interfaces
On Fri, Sep 16, 2011 at 7:34 PM, Ryan Rawson ryano...@gmail.com wrote:
On Fri, Sep 16, 2011 at 7:29 PM, Matt Corgan mcor
So if the HCell or whatever ends up returning ByteBuffers, then that
plays straight in to scatter/gather NIO calls, and if some of them are
DBB, then so much the merrier.
For example, the thrift stuff takes ByteBuffers when its calling for a
byte sequence.
-ryan
On Mon, Sep 19, 2011 at 10:39
Hey this stuff looks really interesting!
On the ByteBuffer, the 'array' byte[] access to the underlying data is
totally incompatible with the 'off heap' features that are implemented
by DirectByteBuffer. While people talk about DBB in terms of nio
performance, if you have to roundtrip the data
. Things are better than they have ever been, but still a lot
of testing to do.
Matt
On Fri, Sep 16, 2011 at 6:08 PM, Ryan Rawson ryano...@gmail.com wrote:
Hey this stuff looks really interesting!
On the ByteBuffer, the 'array' byte[] access to the underlying data is
totally incompatible
think hbase would be great for this.
What exactly about the current system makes it not a viable candidate?
On Fri, Sep 16, 2011 at 7:08 PM, Ryan Rawson ryano...@gmail.com wrote:
On Fri, Sep 16, 2011 at 6:47 PM, Matt Corgan mcor...@hotpads.com wrote:
I'm a little confused over
We thought about it earlier, but single machine needing to come back
up to restore didnt seem like a good idea.
-ryan
On Sat, Sep 3, 2011 at 11:43 PM, Mathias Herberts
mathias.herbe...@gmail.com wrote:
On Sep 4, 2011 1:39 AM, Bill de hÓra li...@dehora.net wrote:
On 02/09/11 19:06, Stack
My understanding is that the ASF is about community, not code. So what
is the goal for Accumulo? Build a community. How much would it
intersect with the HBase community? Sounds like a lot. Does it still
make sense to incubate it then?
To the point earlier that ASF has hosted multiple
PM, Stack st...@duboce.net wrote:
On Sun, Aug 7, 2011 at 9:21 PM, Ryan Rawson ryano...@gmail.com wrote:
Why is this still happening? This was a major issue in the old master.
And still broke?
What happened with this region when you trace it in master logs?
St.Ack
Hi all,
I think we still have a hole in the RIT graph... I get messages like
this in my RS:
2011-08-08 04:17:48,469 WARN
org.apache.hadoop.hbase.regionserver.handler.OpenRegionHandler:
Attempted open of region_name. but already online on this server
And the master UI says the region continues
... along with Google and Yahoo, which means they all each donate at least
$100k per year to ASF.
So in an extended financial sense, Msft supports Hbase by way of their
donation to ASF, but they also support everything else in ASF, just like
the rest of the big donors.
On 8/1/11 10:56 PM, Ryan
You should ask for your money back!!
On Sun, Jul 31, 2011 at 3:10 PM, Fuad Efendi f...@efendi.ca wrote:
What is it all about? HBase sucks. Too many problems to newcomers,
few-weeks-warm-up to begin with Is it really-really
supported by Microsoft employees?!
Each array is really a pointer to an array (hence the references),
then we are taking account of the overhead of the 'bytes' array
itself.
And I see 3 integers pasted in, so things are looking good to me
On Sun, Jul 31, 2011 at 10:01 PM, Akash Ashok thehellma...@gmail.com wrote:
Hi,
I
Someone, but not necessarily the original contributor, should step up and
maintain. Ideally someone who is also using it :)
This could be a good chance to get on the good sides of everyone!
On Jul 14, 2011 11:48 AM, Doug Meil doug.m...@explorysmedical.com wrote:
+1
On 7/14/11 2:16 PM, Andrew
deployments that don't care about the absence of the (a)
and
(b), especially (b), its definitely a viable option that gives good perf.
At MapR, we did consider similar direct-access capability and rejected it
due to the above concerns.
On Fri, Jul 8, 2011 at 6:26 PM, Ryan Rawson ryano
...@explorysmedical.com wrote:
re: If a variant of hdfs-347 was committed,
I agree with what Ryan is saying here, and I'd like to second (third?
fourth?) keep pushing for HDFS improvements. Anything else is coding
around the bigger I/O issue.
On 7/9/11 6:13 PM, Ryan Rawson ryano...@gmail.com wrote:
I
8, 2011 6:20 PM, Jason Rutherglen jason.rutherg...@gmail.com
wrote:
Also, it's for a good cause, moving the blocks out of main heap using
direct byte buffers or some other more native-like facility (if DBB's
don't work).
On Fri, Jul 8, 2011 at 5:34 PM, Ryan Rawson ryano...@gmail.com wrote
is implemented in HBase.
On Fri, Jul 8, 2011 at 6:26 PM, Ryan Rawson ryano...@gmail.com wrote:
The overhead in a byte buffer is the extra integers to keep track of the
mark, position, limit.
I am not sure that putting the block cache in to heap is the way to go.
Getting faster local dfs reads
8, 2011 at 7:05 PM, Ryan Rawson ryano...@gmail.com wrote:
Hey,
When running on top of Mapr, hbase has fast cached access to locally
stored
files, the Mapr client ensures that. Likewise, hdfs should also ensure
that
local reads are fast and come out of cache as necessary. Eg: the kernel
consistent (as Lars
recommends)
and make some of the hbase conf values to more closely match the zk conf
values (though hbase.${zk.value} is really not bad).
-Jesse
From: Ryan Rawson [ryano...@gmail.com]
Sent: Monday, July 04, 2011 5:25 AM
To: dev@hbase.apache.org
Subject: Re: zoo.cfg vs hbase
Should just fully deprecate zoo.cfg, it ended up being more trouble
than it was worth. When you use zoo.cfg you cannot connect to more
than 1 cluster from a single JVM. Annoying!
On Sun, Jul 3, 2011 at 10:22 AM, Ted Yu yuzhih...@gmail.com wrote:
I looked at conf/zoo_sample.cfg from zookeeper
it's own
garbage related ramifications).
you'd need a compressing algorithm
Lucene's terms dict is very simple. The next key has the position at
which the previous key differs.
On Sat, Jun 4, 2011 at 3:35 PM, Ryan Rawson ryano...@gmail.com wrote:
Also, dont break it :-)
Part of the goal
wrote:
On Sun, Jun 5, 2011 at 11:37 PM, Ryan Rawson ryano...@gmail.com wrote:
On Sun, Jun 5, 2011 at 11:33 PM, Jason Rutherglen
jason.rutherg...@gmail.com wrote:
Ok, the block index is only storing the first key of each block?
Hmm... I think we can store a pointer to an exact position
jason.rutherg...@gmail.com wrote:
You'd have to change how the Scanner code works, etc. You'll find out.
Nice! Sounds fun.
On Sat, Jun 4, 2011 at 3:27 PM, Ryan Rawson ryano...@gmail.com wrote:
What are the specs/goals of a pluggable block index? Right now the
block index is fairly tied deep in how
a compressing algorithm, then in the Scanner you would
expand KeyValues
I think we can try that later. I'm not sure one can make a hard and
fast rule to always load the keys into RAM as an FST. The block index
would seem to be fairly separate.
On Sat, Jun 4, 2011 at 3:35 PM, Ryan Rawson ryano
The cost of serialization is non trivial and a substantial expense in
conveying information from regionserver - client. I did some
timings, and sending data across the wire is surprisingly slow, but
attempting to compress it with various compression systems ended up
taking 50-100ms on average
, 2011 at 1:10 PM, Ryan Rawson ryano...@gmail.com
wrote:
I'm -1 on avro as a RPC format. Thrift is the way to
go, any of the
advantages of smaller serialization of avro is lost by
the sheer
complexity of avro and therefore the potential bugs.
I understand the desire to have a pluggable
0.91, if used, will be used for a developer-preview. Much as there
was a 0.89 Developer Preview, then a 0.90.x
DPs tend to be marked by the date they were cut, since there is no
real version, and it is not expected the average user run a DP in
production (nor advised!)
-ryan
On Tue, May 10,
the following case
client#1 update firstName and lastName for a user.
client#2 read the information of the user when client#1 updated firstName
and will update lastName.
so client#1 read the latest firstName, but the old lastName.
Sincerely
On Mon, Mar 28, 2011 at 1:45 PM, Ryan Rawson ryano
Row locks are not necessary when reading. this changed, that is why that is
still there.
On Mar 27, 2011 10:42 PM, jiangwen w wjiang...@gmail.com wrote:
I think a row lock should be obtained before getting a row.
but the following method in HRegion class show a row lock won't be
obtained
the HQuorumPeer uses hbase-site.xml/hbase-default.xml to configure ZK,
including the line Patrick pointed out. You can increase that to
increase the max timeout.
-ryan
On Thu, Mar 24, 2011 at 5:27 PM, Ted Yu yuzhih...@gmail.com wrote:
Seeking more comment.
-- Forwarded message
it would make sense to avoid moving regions, so therefore the more
recently a region was moved, the less likely we should move it.
you could imagine a hypothetical perfect 'region move cost' function
that might look like:
F(r) = timeSinceMoved(r) + size(r) + loadAvg(r)
The functions should
How much memory does profiling indicating these objects use? How much
are you expecting to save?
Saving 4-8 bytes even on a 10k region cluster is still only 80k of
ram, not really significant.
On Thu, Mar 17, 2011 at 2:32 PM, Ted Yu yuzhih...@gmail.com wrote:
Hi,
See email thread 'One of the
with? And not
ganglia :-)
On Thu, Mar 17, 2011 at 2:47 PM, Andrew Purtell apurt...@apache.org wrote:
memstoreSizeMB is part of the output printed by the shell when you do status
'detailed'.
I use that.
Isn't that information useful to others?
- Andy
--- On Thu, 3/17/11, Ryan Rawson ryano...@gmail.com
Is it possible to search a list of z nodes? That is what we do now with meta
in hbase.
I used to be a fan, but I think self hosting all important meta data is the
best approach. It makes lots of things easier, like replication, snapshots,
etc.
On Mar 17, 2011 9:27 PM, jiangwen w
split transaction closes the region, at which time the memstore is
flushed to disk.
at this point they are empty. Dereferenced when HRegion is removed
from the maps, then gced.
On Mon, Mar 14, 2011 at 1:55 AM, Zhou Shuaifeng
zhoushuaif...@huawei.com wrote:
I read the SplitTransaction and
and danger zones. For example it seemed avro would reign
supreme, but the RPC landscape is shifting back towards thrift.
Thanks,
--Suraj
On Sat, Mar 5, 2011 at 2:21 PM, Todd Lipcon t...@cloudera.com wrote:
On Sat, Mar 5, 2011 at 2:10 PM, Ryan Rawson ryano...@gmail.com wrote
) Does asynchbase have any limitations (functionally or otherwise)
compared
to the native HBase client?
Thanks again.
--Suraj
On Sun, Mar 6, 2011 at 9:40 PM, Ryan Rawson ryano...@gmail.com wrote:
On Sun, Mar 6, 2011 at 9:25 PM, Suraj Varma svarma...@gmail.com wrote:
Thanks all for your
I dont think protobuf is winning the war out there, it's either thrift
or avro at this point. Protobuf just isn't an bazzar open-source type
project, and it's non-Java/C++/python support isn't 1st class, plus no
RPC.
As for the past RPC, it's all well to complain that we didn't spend
more time
I'll fix this in a few hours. Not write awake :)
be handled in
the
future by a lock just for loading, and creating a new coprocessor
collection
and assigning when done.
On Tue, Mar 1, 2011 at 12:08 PM, Ryan Rawson ryano...@gmail.com wrote:
My own profiling shows that a read write lock can be up to 3-6% of the
CPU budget in our put/get query path
I'd generally vote for a time-based release. The big feature
releases while are good for attracting new users with new features,
present a problem in that it can really delay releases for a long
time. More releases are better! If a feature takes more than 3
months then it's too big to implement
I filed HBASE-3555, and I listed the following reasons;
- test groups allow us to separate slow/fast tests from each other
- surefire support for running specific groups would allow 'check in
tests' vs 'hudson/integration tests' (ie fast/slow)
- it supports all the features of junit 4, plus it is
Can there be a way to turn it off for those of us who build and use
the .tar.gz but dont want the time sink in generating deb/rpms?
On Thu, Feb 17, 2011 at 1:25 PM, Eric Yang ey...@yahoo-inc.com wrote:
Thanks Ted. I will include this build phase patch with the rpm/deb packaging
patch. :)
builds tarball, rpm and deb.
Does this work for you?
Regards,
Eric
On 2/17/11 1:27 PM, Ryan Rawson ryano...@gmail.com wrote:
Can there be a way to turn it off for those of us who build and use
the .tar.gz but dont want the time sink in generating deb/rpms?
On Thu, Feb 17, 2011 at 1
Well done Andrew.
People who want to know the API differences should probably mostly only read:
https://tm-files.s3.amazonaws.com/hbase/jdiff-hbase-0.90.1/changes/pkg_org.apache.hadoop.hbase.client.html
And specifically the HTable, Put, Get, Delete, Scan classes.
On Wed, Feb 16, 2011 at 7:19
this system over to HBase?
-Todd
On Wed, Feb 16, 2011 at 11:51 AM, Ryan Rawson ryano...@gmail.com wrote:
Well done Andrew.
People who want to know the API differences should probably mostly only
read:
https://tm-files.s3.amazonaws.com/hbase/jdiff-hbase-0.90.1/changes
not very familiar with (internal) HBase APIs which grow quite large.
I have a full-time job.
And this task is quite big.
Community effort should be the best approach.
On Wed, Feb 16, 2011 at 12:20 PM, Todd Lipcon t...@cloudera.com wrote:
On Wed, Feb 16, 2011 at 12:16 PM, Ryan Rawson ryano
hregion is the internal implementation of a region inside
regionserver, you dont get it from a client.
that data is being sent to the master, it's being published to ganglia
and the metric system.
On Fri, Feb 11, 2011 at 1:23 PM, Ted Yu yuzhih...@gmail.com wrote:
HTable can return region
I am generally +1, but we'll need another RC to address HBASE-3524.
Here is some of my other report of running this:
Been running a variant of this found here:
https://github.com/stumbleupon/hbase/tree/su_prod_90
Running in dev here at SU now.
Also been testing that against our Hadoop CDH3b2
, 2011 at 9:59 PM, Ryan Rawson ryano...@gmail.com wrote:
I am generally +1, but we'll need another RC to address HBASE-3524.
Here is some of my other report of running this:
Been running a variant of this found here:
https://github.com/stumbleupon/hbase/tree/su_prod_90
Running in dev here at SU
my jar looks like:
-rw-r--r-- 1 hadoop hadoop 2861459 2011-02-09 16:34 hadoop-core-0.20.2+322.jar
-ryan
On Fri, Feb 11, 2011 at 10:29 PM, Ryan Rawson ryano...@gmail.com wrote:
I put up the patch I used, I then changed the version to 0.20.2-322
and just did ant jar. I crippled the forrest
, 2011 at 10:29 PM, Ryan Rawson ryano...@gmail.com wrote:
I put up the patch I used, I then changed the version to 0.20.2-322
and just did ant jar. I crippled the forrest crap in build.xml... I
didnt check the filesize of the resulting jar though.
-ryan
On Fri, Feb 11, 2011 at 10:08 PM, Ted
PM, Ryan Rawson ryano...@gmail.com wrote:
i call it 0.20.2-322 and its at http://people.apache.org/~rawson/repo/ (m2
repo)
for just the jar you can find it there.
On Fri, Feb 11, 2011 at 10:35 PM, Ted Yu yuzhih...@gmail.com wrote:
Is it possible for you to share the hadoop-core-0.20.2+320
You don't have both the old and the new hbase jars in there do you?
-ryan
On Thu, Feb 10, 2011 at 3:12 PM, Ted Yu yuzhih...@gmail.com wrote:
.META. went offline during second flow attempt.
The time out I mentioned happened for 1st and 3rd attempts. HBase was
restarted before the 1st and 3rd
there wasn't
exception in server log
I think a JIRA should be filed for item 2 above - bail out when the two
hbase jars from $HBASE_HOME and $HBASE_HOME/lib are of different versions.
Cheers
On Thu, Feb 10, 2011 at 3:40 PM, Ryan Rawson ryano...@gmail.com wrote:
What do you get when you:
ls
Kennedy
Project Manager
Troove Inc.
On 2011-02-10, at 10:46 PM, Ryan Rawson wrote:
I am speaking off the hip here, but the major compaction algorithm
attempts to keep the number of major compactions to a minimum by
checking the timestamp of the file. So it's possible that the other
regions
, 2011 at 11:43 AM, Ryan Rawson ryano...@gmail.com wrote:
A mvn release (to maven central) is different than our standard
tarball (assembly:assembly), right?
Yeah. There is a 'release' mvn plugin that wants to 'help' you in the
way that mswindows is always trying to help you; you know, Would
how many versions is the column family configured for? the
maxVersions will never return more than that, so if it is 1 you wont
have more than 1.
-ryan
On Thu, Jan 27, 2011 at 3:08 PM, Vladimir Rodionov
vrodio...@carrieriq.com wrote:
Although this version is not supported but may be somebody
the call to compactionRequested() only puts the region on a queue to
be compacted, so if there is unintended duplication, it wont actually
hold anything up.
-ryan
On Tue, Jan 25, 2011 at 6:05 PM, mac fang mac.had...@gmail.com wrote:
Guys, since the flushCache will make the write/read suspend. I
dont forget that this wont parallelize the flushes or compactions,
since they happen region-server side and there are built in limits
there to keep io down.
this will accelerate sending all the command messages though.
-ryan
On Mon, Jan 24, 2011 at 11:18 AM, Ted Yu yuzhih...@gmail.com wrote:
Hopefully to do #1, you would not require many/any changes in HFile or
HBase. Implementing the HDFS stream API should be enough.
#2 is interesting, what is the benefit? How did you measure said benefit?
-ryan
On Sat, Jan 22, 2011 at 5:45 PM, Ted Yu yuzhih...@gmail.com wrote:
#1 looks similar
the parse code inside table.rb is wacky, maybe this fixes it:
diff --git a/src/main/ruby/hbase/table.rb b/src/main/ruby/hbase/table.rb
index c8e0076..cd90132 100644
--- a/src/main/ruby/hbase/table.rb
+++ b/src/main/ruby/hbase/table.rb
@@ -138,19 +138,17 @@ module Hbase
no it does not, zookeeper fixed that.
-ryan
On Tue, Jan 18, 2011 at 3:29 PM, Ted Yu yuzhih...@gmail.com wrote:
Hi,
In hbase 0.20.6, I see the following in description for
zookeeper.session.timeout:
The current implementation
requires that the timeout be a minimum of 2 times the
cluster. Each
node
has
half the number of cores as the node in staging.
I agree with your conclusion.
I will report back after I collect more data - the flow uses hbase
heavily
toward the end.
On Fri, Jan 14, 2011 at 6:20 PM, Ryan Rawson ryano...@gmail.com
wrote
Hey,
It's a pretty unusual situation that got you into 3445? It's been a
few weeks of RCs, and we need to push out a 0.90.0 so everyone can
benefit from it. We can release point releases fairly quickly once a
stable base release is out, does that sound reasonable to you?
Thanks for testing!
This is the cause:
org.apache.hadoop.hbase.regionserver.HRegionServer: ABORTING region server
serverName=sjc1-hadoop1.sjc1.carrieriq.com,60020,1294856823378,
load=(requests=0, regions=6, usedHeap=514, maxHeap=3983):
regionserver:60020-0x12d7b7b1c760004 regionserver:60020-0x12d7b7b1c760004
master web UI, This happened after I doubled the amount
of data processed in our flow.
I am attaching master log.
On Fri, Jan 14, 2011 at 3:10 PM, Ryan Rawson ryano...@gmail.com wrote:
This is the cause:
org.apache.hadoop.hbase.regionserver.HRegionServer: ABORTING region server
serverName
There was a good, but complex reason. Its going away with stacks time stamp
patch. I'll see if I can do a better email tomorrow.
On Jan 9, 2011 11:42 PM, Dhruba Borthakur dhr...@gmail.com wrote:
I am looking at Hregion.incrementColumnValue(). It has the following piece
of code
// build the
st...@duboce.net wrote:
Yeah, thats going away unless Ryan comes up w/ a reason for why we
should keep it.
St.Ack
On Mon, Jan 10, 2011 at 12:29 AM, Ryan Rawson ryano...@gmail.com wrote:
There was a good, but complex reason. Its going away with stacks time stamp
patch. I'll see if I can do
else.
-Original Message-
From: Ryan Rawson [mailto:ryano...@gmail.com]
Sent: Monday, January 10, 2011 2:27 PM
To: dev@hbase.apache.org
Subject: Re: question about Hregion.incrementColumnValue
I put more comments on this:
HBASE-3021
Basically we needed to avoid duplicate timestamp
Oh no, let's be wary of those server rewrites. My micro profiling is
showing about 30 usec for a lock handoff in the HBase client...
I think we should be able to get big wins with minimal things. A big
rewrite has it's major costs, not to mention to effectively be async
we'd have to rewrite
just run 'mvn install' in our directory and that should do the trick.
everything else is implied by pom.xml. well except the repository
stuff.
-ryan
On Wed, Dec 29, 2010 at 10:29 AM, Ted Yu yuzhih...@gmail.com wrote:
Hi,
I used the following script to deploy hbase 0.90 jar to internal maven
Looks like the fight does not go well. A lot of hdfs developers are
concerned that it would detract resources. I'm not sure who's
resources.
I hope my 13-15 month commented helped... I've heard wait for the
next version before and I am not interested in it. If that indeed
worked, a year ago
The default xml is in the jar and is intended to be that way. Thee other is
a bug. Can you file a jira? Thanks!
On Dec 21, 2010 7:18 PM, Tatsuya Kawano tatsuya6...@gmail.com wrote:
Hi,
Just noticed a couple of things in the last candidate (rc1).
1. conf/hbase-default.xml is missing.
2.
...@maprtech.com wrote:
From the small comments I have heard, the RAM versus disk difference is
mostly what I have heard they were testing.
On Wed, Dec 15, 2010 at 11:11 AM, Ryan Rawson ryano...@gmail.com wrote:
We dont have the test source code, so it isnt very objective. However
I believe there are 2
report about how G1 is coming along?
On Wed, Dec 15, 2010 at 11:22 AM, Ryan Rawson ryano...@gmail.com wrote:
As G1 GC improves, I expect our ability to use larger and larger heaps
would blunt the advantage of a C++ program using malloc.
per machine?
Chad
-Original Message-
From: Ryan Rawson [mailto:ryano...@gmail.com]
Sent: Wednesday, December 15, 2010 11:52 AM
To: dev@hbase.apache.org
Subject: Re: Hypertable claiming upto 900% random-read throughput vs HBase
The malloc thing was pointing out that we have
Hi,
I'd like to hear more on how you think this paper and the associated
topics apply to HBase. Remember, unlike the paper, everyone will
always run replication in a real environment, it would be suicide not
to.
-ryan
On Mon, Dec 6, 2010 at 11:39 AM, Vladimir Rodionov
vrodio...@carrieriq.com
So are we talking about re-implementing IO scheduling in Hadoop at the
application level?
On Mon, Dec 6, 2010 at 12:13 PM, Rajappa Iyer r...@panix.com wrote:
Jay Booth jaybo...@gmail.com writes:
I don't get what they're talking about with hiding I/O limitations.. if the
OS is doing a poor
While I applaud these experiments, the next challenge is getting them
in to a shipping Hadoop. I think it's a relative nonstarter if we
require someone to patch in a bunch of patches that are/were being
refused to be committed.
Keep on experimenting and collecting that evidence though! One day!
On 2010-11-30 09:57:27, Ryan Rawson wrote:
branches/0.90/src/main/java/org/apache/hadoop/hbase/io/hfile/HFile.java,
line 765
http://review.cloudera.org/r/1261/diff/1/?file=17902#file17902line765
why would you not want to evict blocks from the cache on close?
stack wrote
---
This is an automatically generated e-mail. To reply, visit:
http://review.cloudera.org/r/1252/#review1993
---
trunk/src/main/java/org/apache/hadoop/hbase/KeyValue.java
lars.geo...@gmail.com wrote:
OK, got it. I missed the HRegionServers.next() in the mix. It calls
the RegionScanner.next(results) and that uses the batch. Tricksy! I
should have started on the client side instead.
Lars
On Fri, Nov 26, 2010 at 3:08 AM, Ryan Rawson ryano...@gmail.com wrote
On 2010-11-26 14:54:45, Ryan Rawson wrote:
trunk/src/main/java/org/apache/hadoop/hbase/KeyValue.java, line 1373
http://review.cloudera.org/r/1252/diff/1/?file=17712#file17712line1373
what are all the consequences for not sorting by type when using
KVComparator? Does this mean we
limit is for retrieving partial results of a row. Ie: give me a row
in chunks. Filters that want to operate on the entire row cannot be
used with this mode. i forget why it's in the loop but there was a
good reason at the time.
-ryan
On Thu, Nov 25, 2010 at 10:51 AM, Lars George
Please include a diff instead, it's hard to compare.
Also I'm not sure there will be a 0.20.7.
-ryan
On Wed, Nov 24, 2010 at 3:45 PM, Ted Yu yuzhih...@gmail.com wrote:
Hi,
I wanted to automate the manual deletion of dangling row(s) in .META. table.
Please kindly comment on the following
Hi,
You could implement this in a code structure like so:
HTable table = new HTable(tableName, conf);
Put lastPut = null;
while ( moreData ) {
Put put = makeNewPutBasedOnLastPutToo( lastPut, dataSource );
table.put(put);
lastPut = put;
dataSource.next();
}
if that is
I concur. Next week?
On Wed, Nov 17, 2010 at 4:39 PM, Stack st...@duboce.net wrote:
Good one. Want to make an issue J-D?
Seems like this RC is sunk going by issues filed against it. If its
OK w/ you all lets let this RC hang out there a little longer to
see if the RC catches more bad
That is correct, those classes were deprecated in 0.20, and now gone in 0.90.
Now you will want to use HTable and Result.
Also Filter.getNextKeyHint() is an implementation detail, have a look
at the other filters to get a sense of what it does.
On Mon, Nov 15, 2010 at 12:33 PM, Ted Yu
1 - 100 of 189 matches
Mail list logo
