Yeah the reason ask about having the community support it is because the thrift interfaces are all internal workings, thus, code other than the client API should probably be maintained internally. This will add a slight overhead to development and maintenance of these thrift services because more implementations will now need to be kept up to date and modified when changes need to be implemented.
Not saying it should be a showstopper, just pointing it out. On Mon, Oct 6, 2014 at 4:15 PM, David Medinets <david.medin...@gmail.com> wrote: > How far away from the theoretical maximum rate is the thrift protocol? > What kind of gain is expected from the native C++ approach? > > On Sat, Oct 4, 2014 at 12:56 PM, John R. Frank <j...@diffeo.com> wrote: > > Accumulo Developers, > > > > We're trying to boost throughput of non-Java tools with Accumulo. It > seems that the lowest hanging fruit is to stop using the thrift proxy. Per > discussion about Python and thrift proxy in the users list [1], I'm > wondering if anyone is interested in helping with a native C++ client? > There is a start on one here [2]. We could offer a bounty or maybe make a > consulting project depending who is interested in it. > > > > We also looked at trying to run a separate thrift proxy for every worker > thread or process. With many cores on a box, eg 32, it just doesn't seem > practical to run that many proxies, even if they all run on a single JVM. > We'd be glad to hear ideas on that front too. > > > > A potentially big benefit of making a proper C++ accumulo client is that > it is straightforward to expose native interfaces in Python (via pyObject), > Go [3], Ruby [4], and other languages. > > > > Thanks for any advice, pointers, interest. > > > > John > > > > > > 1-- http://www.mail-archive.com/user@accumulo.apache.org/msg03999.html > > > > 2-- > > https://github.com/phrocker/apeirogon > > > > 3-- http://golang.org/cmd/cgo/ > > > > 4-- https://www.amberbit.com/blog/2014/6/12/calling-c-cpp-from-ruby/ > > > > > > Sent from +1-617-899-2066 >
