Re: HTable thread safety in 0.20.6

Google's protobufs make this problem more palatable with optional params. Of course, you will have to break versions once more On Fri, Mar 4, 2011 at 10:04 AM, Stack wrote: > On Fri, Mar 4, 2011 at 12:24 AM, tsuna wrote: > > In practice, bear in mind that HBase has a bad track record of >

Build failed in Jenkins: HBase-TRUNK #1769

See Changes: [garyh] HBASE-3582 Allow HMaster and HRegionServer to login from keytab when running on secure Hadoop [stack] HBASE-3603 Remove -XX:+HeapDumpOnOutOfMemoryError autodump of heap option on OOME [stack] HBASE-3605 Fix

Jenkins build is back to normal : hbase-0.90 #102

See

Re: HTable thread safety in 0.20.6

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 :) -- Benoit "tsuna" Sigoure S

Jenkins build is back to normal : hbase-0.90 #100

See

Re: HTable thread safety in 0.20.6

On Fri, Mar 4, 2011 at 12:24 AM, tsuna wrote: > In practice, bear in mind that HBase has a bad track record of > breaking backward compatibility between virtually every release (even > minor ones), although they often bump the protocol version number even > though there are no client-visible API c

Build failed in Jenkins: HBase-TRUNK #1768

See Changes: [stack] Fix client dependencies (Lars George via Stack) -- [...truncated 2978 lines...] Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 131.924 sec Running org.apa

Re: HTable thread safety in 0.20.6

On Thu, Mar 3, 2011 at 8:34 PM, Suraj Varma wrote: > This is interesting - so, doesn't asynchbase have any dependency on hbase > jar or hadoop jar? How does it achieve this version independence? Yes asynchbase doesn't depend on the HBase jar or Hadoop jar. It's just a re-implementation of the HB