On Thu, Oct 13, 2011 at 1:05 PM, Jean-Daniel Cryans <[email protected]>wrote:
> On Thu, Oct 13, 2011 at 8:17 AM, Norbert Burger <[email protected] > >wrote: > > > In the ticket, I mentioned setting hbase.client.write.buffer as a > > workaround, but unfortunately it doesn't seem that autoflush (which I > > imagine has a bigger impact on write performance) isn't exposed. > > > Configuring this would make no difference at all without turning off auto > flush since the thrift API also doesn't allow mutations on multiple rows in > the same batch. > > BTW, can your app support the semantics of having auto flush off? What's > your use case like? > By semantics, do you mean the possibility that unflushed data might be lost if the client goes away? Our app pulls from a queue that supports acknowledgement, so that side is ok. But as you may be pointing out, we can only fire receipt acknowledgement on explicit buffer flushes (eg., flushCommit()) , so we'd have to somehow disable implicit flushing (because the write buffer filled up). Thanks for the heads-up. Norbert
