I'm generally a proponent of gRPC for all of the reasons aforementioned, but it's worth mentioning that it's purely intended for light message payloads. I admit that I don't have intimate knowledge of the thrift payloads in Accumulo, but I do know how large <K,V> pairs can be. They (Google) say if payload sizes are expected to exceed 1MB, an alternate strategy should be considered.
Here's their blurb on protobuf payloads: https://developers.google.com/protocol-buffers/docs/techniques#large-data Thanks, Mike On Fri, Nov 17, 2017 at 8:43 AM Jorge Machado <jorge.w.mach...@hotmail.com> wrote: > Do we have a List of topics with thrift problems ? > > Jorge Machado > jo...@jmachado.me<mailto:jo...@jmachado.me> > > > Am 17.11.2017 um 13:21 schrieb Josh Elser <els...@apache.org<mailto: > els...@apache.org>>: > > Did you offer to make the release? See me with commons-vfs a time back. > > Your proposal seems to me like you're blowing the situation out of > proportion. > > On Nov 16, 2017 23:58, "Christopher" <ctubb...@apache.org<mailto: > ctubb...@apache.org>> wrote: > > The current Thrift issue has already been fixed with a patch. Their PMC > needs to release it, though. > > Following ASF's commitment to "community over code", I think it would be > inappropriate for an Apache project to fork another active project while > that community still exists. It's better to work with them if we can, and > to use another dependency if we can't. There may be ASF policy against such > forking, but that may only apply to forking non-ASF projects. In any case, > I don't think it's a good idea. > > Also, even if we are able to resolve the current issue of releasing a > version without the spammy print statement, I think there's value in > discussing possible alternatives and their pros/cons. There's no timeline > for this. Consider this an open-ended discussion regarding RPC > alternatives. I just want to gather those alternatives into one place to > discuss. > > > On Thu, Nov 16, 2017 at 11:43 PM Ed Coleman <d...@etcoleman.com<mailto: > d...@etcoleman.com>> wrote: > > Have we tried fixing the current issue and then submitting a > pull-request? > > I'd favor first submitting a pull request and any other help that we can > provide to get it adopted and released soon - failing that we could fork > the project and go from there. That could offer us a path to correct the > immediate issue and offer time to consider other alternatives. > > Ed Coleman > > -----Original Message----- > From: Christopher [mailto:ctubb...@apache.org] > Sent: Thursday, November 16, 2017 11:36 PM > To: accumulo-dev <dev@accumulo.apache.org<mailto:dev@accumulo.apache.org>> > Subject: [DISCUSS] Moving away from Thrift > > Accumulo Devs, > > I think it's time we start seriously thinking about moving away from > Thrift and considering alternatives. > For me, https://issues.apache.org/jira/browse/THRIFT-4062 is becoming > the > last straw. > > Thrift is a neat idea, but to be blunt: there seems to be a fundamental > lack of care or interest from the Thrift developers at the current > moment. > > Some of the problems we've seen over the years: Every version is > fundamentally incompatible with other versions. Repeated flip-flopping > regressions seems to occur with each release. Fundamental design concepts > like distinguishing server-side exceptions (TApplicationException vs. > TException) are undermined without consideration of the initial design. > And now, a serious bug (a spammy debugging print statement) was left in > for > nearly a year now (still exists in current version), and no response from > the PMC to indicate any willingness to release a fix. Repeated requests > to > the developer list has gone ignored. And, I'm not even counting my > requests > for assistance debugging a compiler issue on s390x arch having also gone > ignored. > > These problems are not exclusive to Accumulo. Many of these are problems > that Cassandra has also faced, and I'm sure there are others. > > It's possible that Thrift can remedy the situation. None of these > problems > are insurmountable, and none of them are beyond fixes, particularly if we > can afford to volunteer more to help out. My intention is not to throw a > fellow Apache project under the bus, and I do not intend to give up > reporting bugs, and contributing patches to Thrift where appropriate. > But, > I think we also need to think realistically, and consider alternatives, > if > Thrift development does not go in a direction which is favorable to > Accumulo. > > So, with that in mind, any suggestions for alternatives? With pros/cons? > > > >
