Jenkins build is back to normal : HBase-TRUNK #2125

See

Re: HBASE-1730 and HBASE-4213

Nileema: I should apologize for the late effort of trying to converge two very different designs at such a late stage. I feel you have expressed the approach of 4213. Thanks for your understanding. There is definitely pearl in your patch. E.g. Ruby script enhancements. If you and Subbu can wo

Re: HBASE-1730 and HBASE-4213

Hi Nileema, Absolutely no need for apologies. Actually I never realized that you were also working on the same and saw your patch when I was about to commit my patch. I created a new JIRA (4213) just so that I can bring up an additional option to the table with out polluting or hijacking your e

Re: HBASE-1730 and HBASE-4213

Hi Guys, Thank you for starting a thread to bring this to closure. I have only read Subbu's description of the approach. I believe the main difference is that 4213 uses the zookeeper to maintain if all regions have the updated schema and reopening the regions is the RegionServer's responsibility,

Re: Thanks -- and intro to Jon and Rehmi

Jon said I could follow up to the list in order to get others involved. The context here is in the solution of very large over-determined systems which, interestingly enough, are not sparse. Thus, they potentially have billions of rows versus thousands of columns. On Tue, Aug 16, 2011 at 5:14 PM

Re: HBASE-1730 and HBASE-4213

On Fri, Aug 19, 2011 at 3:04 AM, Ted Yu wrote: > Surely they do. > If they summarize their plan, it would be easier for others to make a > decision. > > I'd tend to think its their decision to make. We are just here to cheer them on (smile). Subbu you going to come to the hackathon (http://www

Re: HBASE-1730 and HBASE-4213

Surely they do. If they summarize their plan, it would be easier for others to make a decision. On Aug 18, 2011, at 7:59 PM, Stack wrote: > On Fri, Aug 19, 2011 at 12:53 AM, Ted Yu wrote: >> Let's vote on which implementation is the better approach. >> > > Don't the authors of the patches

Re: HBASE-1730 and HBASE-4213

On Fri, Aug 19, 2011 at 12:53 AM, Ted Yu wrote: > Let's vote on which implementation is the better approach. > Don't the authors of the patches get a say? St.Ack

Re: HBASE-1730 and HBASE-4213

> Using zookeeper to record transient state is Andy's favorite choice. Ted, thank you for the consideration!   Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White) - Original Message - > From: Ted Yu > To: dev@hbase.apache.o

Re: HBASE-1730 and HBASE-4213

I prefer choice A below. Let's vote on which implementation is the better approach. My vote is for 4213. Subbu implemented hbase-451 and has deep understanding of related code. Using zookeeper to record transient state is Andy's favorite choice. Cheers On Thu, Aug 18, 2011 at 5:29 PM, Todd Lipc

Re: HBASE-1730 and HBASE-4213

In my opinion we have three options: (a) have the two contributors work together on a single JIRA (b) factor out what's common between their approaches into a new JIRA, then let them proceed independently or (c) let them proceed independently, and whichever one reaches a suitable commitable state

HBASE-1730 and HBASE-4213

Hi, Due to lack of coordination, HBASE-1730 and HBASE-4213 try to implement the same feature at roughly the same pace. I want to hear your opinion on how we should plan to move forward with these two JIRAs. One possibility is to provide two policies, one accommodating each JIRA. But that requires

Build failed in Jenkins: HBase-TRUNK #2124

See Changes: [tedyu] HBASE-4175 Fix FSUtils.createTableDescriptor() -- [...truncated 1511 lines...] Running org.apache.hadoop.hbase.rest.model.TestCellModel Tests run: 3, Failures: 0, Errors: 0, Skip

Re: HBase exception after upgrading from hbase-0.90-branch to trunk

i'm running hbase and hadoop at my home on laptop and pc with atom prosessor so hadoop is under replicated and there are lags because of wifi connection. this is few lines from master log: 2011-08-18 21:09:30,128 DEBUG org.apache.hadoop.hbase.zookeeper.ZKUtil: master:6-0x31de4bb662 Ret

HBASE-4175

I plan to commit HBASE-4175 patch v3 today. If you have review comments, feel free to share. Thanks

Re: HBase exception after upgrading from hbase-0.90-branch to trunk

Can you redo with logs at DEBUG level? This seems like a migration issue -- i.e. migrating the catalog tables from old format to new -- but from what I can see in the logs, its more an issue w/ state transitions in zk... I need the DEBUG logging to tell for sure. St.Ack On Thu, Aug 18, 2011 at 8

Build failed in Jenkins: HBase-TRUNK #2123

See Changes: [stack] HBASE-4176 Exposing HBase Filters to the Thrift API [stack] HBASE-4176 Exposing HBase Filters to the Thrift API -- [...truncated 1523 lines...] Tests run: 3, Failures: 0, Errors

Re: HBase exception after upgrading from hbase-0.90-branch to trunk

Hi, comments inline: On 16.08.2011 06:42, Stack wrote: Oh, are you running on hbase trunk? If so, did you write all your data with TRUNK or did you start up 0.92 on a data that was written w/ 0.90 (It should work but you may have hit an issue). I had branch-0.90 and after proper shutdown i had