rst RC of any new major release. :P
--
Benoit "tsuna" Sigoure
On Mon, Jan 27, 2014 at 9:48 AM, Jonathan Hsieh wrote:
> So is the suggestion to just add the other signature to hbase's version?
The existing signature is useless as it cannot be used from outside
Google's protobuf package.
--
Benoit "tsuna" Sigoure
agree on the API.
I don't expect this class to change much if at all anyway. It's just
really unfortunate that this method was changed, what's more with a
signature that renders it unusable.
--
Benoit "tsuna" Sigoure
If this RC sinks, can you please include this one in 0.98.0:
https://issues.apache.org/jira/browse/HBASE-10422
--
Benoit "tsuna" Sigoure
r.run(NioWorker.java:178)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
>
> It will be very simple to rename ZeroCopyLiteralByteString class in
> asynchbase into something different and republish new jar.
> Hope, someone may propose better solution.
--
Benoit "tsuna" Sigoure
d / cleaned up.
--
Benoit "tsuna" Sigoure
reads that are much faster now
that HBASE-9428 is fixed.
--
Benoit "tsuna" Sigoure
On Sat, Oct 27, 2012 at 5:46 PM, lars hofhansl wrote:
> Any value between 10 and 1000 should be OK, really. Maybe the default should
> be 100.
FWIW, asynchbase uses 128 rows as the default for its scanners, and
4096 maximum KVs by default too.
--
Benoit "tsuna" Sigoure
ocol) it's
worthwhile to start looking at integrating support for the new
protocol in asynchbase.
--
Benoit "tsuna" Sigoure
obuf, then you know it's HBase >= 0.96, parse the
protobuf and find where the META table is and what protocol version it
expects.
- Otherwise, it's not a protobuf, keep doing whatever we were doing
prior HBase 0.96.
--
Benoit "tsuna" Sigoure
Software Engineer @ www.StumbleUpon.com
e APIs clean, then I think it's worthwhile.
--
Benoit "tsuna" Sigoure
Software Engineer @ www.StumbleUpon.com
om scratch for about 2
years now, I can tell you that the only things I had to fix across
HBase release were wire-level serialization breakages. The heavy
logic of the client has remained mostly unchanged since the days of
HBase 0.20.
--
Benoit "tsuna" Sigoure
Software Engineer @ www.StumbleUpon.com
multiple instances where the DBA team and
> the AppServer team are different people, especially with any group
> exploring multi-tenancy. For that use case, client & server compat is
> critical.
Agreed.
--
Benoit "tsuna" Sigoure
Software Engineer @ www.StumbleUpon.com
fully. But asynchbase can do this because it's asynchronous.
You can't have a useful write buffer that's synchronous, because it
would mean that as soon as you call put(), you get blocked until the
buffer is flushed. Well you can always compensate by creating a
shitload of thr
and then very rarely as servers hosting
.META. and -ROOT- fail).
--
Benoit "tsuna" Sigoure
Software Engineer @ www.StumbleUpon.com
side, so we can finally move away from the inefficient
model with thread pools containing hundreds of threads.
> Based on discussion below, is async-hbase a "thick" / smart client or
> something less than that?
asynchbase is a thick client too, it implements all the logic that is
needed to use HBase. Some of the logic is actually implemented
slightly differently, but as far as end-users are concerned these are
implementation details (for better performance / reliability /
scalability).
--
Benoit "tsuna" Sigoure
Software Engineer @ www.StumbleUpon.com
On Fri, Mar 4, 2011 at 10:04 AM, Stack wrote:
> At Benoit's suggestion, we've changed the way we version Interfaces;
> rather than a global version for all, we now version each Interface
> separately. More to come...
Yup, thank you very much for implementing this :)
--
Ben
emented in such a way that the
client will be able to detect different server versions and adjust
itself accordingly. Eventually, I hope it'll be possible to have
rolling upgrades of a cluster, at least between minor versions.
--
Benoit "tsuna" Sigoure
Software Engineer @ www.StumbleUpon.com
nd up and very efficient
in a multi-threaded application that uses HBase as a backend. It also
works with all HBase versions, whereas with HTable you need to change
the .jar and restart your application whenever you want to switch
between different versions.
--
Benoit "tsuna" S
On Mon, Feb 7, 2011 at 10:59 AM, Todd Lipcon wrote:
> Unfortunately you can't get at any of the really juicy details like CMS FLS
> statistics :(
Do you have to resort to reading back your own GC log to figure this
stuff out? :(
--
Benoit "tsuna" Sigo
the hood
it starts a thread in the remote JVM to handle RMI calls that probably
go over the loopback interface. This is pretty much how jconsole and
friends work, BTW. Pretty horrible stuff. :(
--
Benoit "tsuna" Sigoure
Software Engineer @ www.StumbleUpon.com
to make good load balancing decisions. If the
master has information such as QPS per region, latency per region,
number of GC cycles per GC type, then it can get a pretty clear
picture of the load of each RS and try to even it out.
--
Benoit "tsuna" Sigoure
Software Engineer @ www.StumbleUpon.com
me allows for opportunities such as warming up the
block cache in the destination RS before it starts serving.
--
Benoit "tsuna" Sigoure
Software Engineer @ www.StumbleUpon.com
show anything useful here, the machine is
100% idle up until the 3rd section where it's reading a bit from disk,
but it's still mostly idle. Something else that we don't see from
this trace is amiss.
--
Benoit "tsuna" Sigoure
Software Engineer @ www.StumbleUpon.com
always be 0.
What's printed by /sbin/sysctl vm.swappiness ?
--
Benoit "tsuna" Sigoure
Software Engineer @ www.StumbleUpon.com
It could be useful to see the output of "vmstat 1" (let it run for at
least 30 seconds while the problem is occurring and pastebin the
result). If the problem seems i/o related, the output of "iostat -xkd
1" can also help.
--
Benoit "tsuna" Sigoure
Software Engineer @ www.StumbleUpon.com
On Thu, Jan 20, 2011 at 2:58 PM, Todd Lipcon wrote:
> On Thu, Jan 20, 2011 at 2:52 PM, tsuna wrote:
>
>> On Thu, Jan 20, 2011 at 9:33 AM, Todd Lipcon wrote:
>> > I did some experiments to understand our full GC issues better last
>> night.
>>
On Thu, Jan 20, 2011 at 9:33 AM, Todd Lipcon wrote:
> I did some experiments to understand our full GC issues better last night.
> Here are the results:
> http://people.apache.org/~todd/hbase-fragmentation/
Just curious: what hardware configuration was used during this test?
--
Beno
u guys
> don't think it's a good idea.
I think dev ML is already a good enough for this purpose.
PS: http://github.com/stumbleupon/asynchbase
--
Benoit "tsuna" Sigoure
Software Engineer @ www.StumbleUpon.com
inal Object PRESENT = new Object();
[...]
public boolean add(E e) {
return map.put(e, PRESENT)==null;
}
--
Benoit "tsuna" Sigoure
Software Engineer @ www.StumbleUpon.com
to trust what people like
Joshua Bloch write, but I can be convinced otherwise :)
--
Benoit "tsuna" Sigoure
Software Engineer @ www.StumbleUpon.com
On Mon, May 24, 2010 at 11:54 PM, Stack wrote:
> Good on you Todd,
Congrats Todd, very well deserved with all the good work you've been
doing for HBase recently! Two thumbs up for you, keep up the good
work!
--
Benoit "tsuna" Sigoure
Software Engineer @ www.StumbleUpon.com
32 matches
Mail list logo
