hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From va...@hashmapinc.com
Subject Re: What's going on? Two C++ clients being developed at the moment?
Date Tue, 19 Apr 2016 05:59:10 GMT
 

On 2016-04-18 21:41, Elliott Clark wrote:
> On Mon, Apr 18, 2016 at 4:57 PM, Devaraj Das <ddas@hortonworks.com> wrote:
> 
>> 1. Be able to do async RPC. Vamsi's current implementation does sync. I
>> know Vamsi is already looking at that aspect. Just to be clear, this in my
>> mind this doesn't qualify as a blocker - since we don't have an async
>> client API to support yet.
>>
> 
> There's no deadline on creating a good client. We should do what's better
> not what's fastest to implement. We know that the way HBase is used results
> in way too many threads if everything is sync. There's no prize for getting
> things done before they are the best possible. We should be learning from
> our many many mistakes in the first client and creating something better.
> We shouldn't be re-creating the same exact mess in a different language.
> 
> There's no backwards compat rules, so we should make what works the best
> for HBase going forward. And as clusters get larger and larger one thread
> per server or per request is not going to scale. We're already in a place
> that the number of threads is a factor. Just imagine as clusters continue
> to grow. Locking and context switches will abound.
> 
> 
>> 2. Switch to C++ ways of configuring the hbase client configuration. This
>> is something I am really not sure about. By going this route, we'd have to
>> be able to manage two different ways of configuring things - one for Java
>> and another for C++. This will lead to unnecessary duplication of configs
>> and such (and the deployment tools would now have to be aware about a new
>> way of configuring c++ clients). But we can take a look at making this
>> configuration method pluggable if it makes sense.
>>
> 
> We should do what is best for each use case. You don't see xml going well
> with python, ruby, javascript configs. If the native client is going to be
> used by people outside of the java world, then we should give them the
> experience that delights them. Not that makes them think about java. None
> of the best designed libraries in cpp that I can think of use an xml file
> for a config.
> 
> Elliott, regarding your concern as to who would support the large code drop
>> .. we did talk about breaking the patch up into smaller ones if it makes
>> sense for reviews and such.
>>
> 
> Splitting it up is nice, and shows that software is being developed in the
> open, and not code dropped. However my concern is less about the size of
> the patch and more about the body of work being supported. HBase has had a
> bad history of taking code, having no one support it, and then having bit
> rot in our repository.
> 
> 
>> I think Vamsi has already addressed the other concerns to do with
>> Copyright headers, etc.
>>
> 
> Sorry this hasn't been addressed at all.

I beg to differ as this has been addressed from the source code
standpoint. 
As to the build scripts, the concerned person will respond.

> There are copyright headers from other projects (install-sh, missing).
> Importing some code from other projects seems dubious at best. And at worst
> seems like copy paste. That could come back and bite us. Once trust in a
> code's origin is lost it's really hard to integrate it. I don't want to
> have to go through every line and see where it came from.
> 
> There's other people's names in the code. Everyone who wrote the code needs
> to assign copyright to Apache. Saying "I worked with someone else, I can
> remove their name" is not fixing the issue.

Developing this C++ client is a team effort. We used Eclipse IDE as our
dev. environment.
Whenever we added new source files, the default template injected our
names into those files.
After your feedback, we fixed our templates. I don't know of any other
way to fix this issue. I certainly
welcome constructive criticism. Please suggest a better way to fix this
issue without "removing our names".
I also replied to your feedback in the review board that this source
code was written from scratch. How can we import
code that was never implemented before? I mean the C++ code.

> There's GNU licensed code. GNU is specifically called out as not being able
> to be in our repos.
> 
> None of these are addressed and to be honest they scare me. We can move
> fast and import code that's not 100% working or tested. But playing fast
> and loose with laws is just another thing entirely.

 
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message