I'm reluctant to use any protobuf-based RPC framework, because I think protobuf has similar issues with incompatibilities between versions as Thrift does. There does seem to be more tooling for it, though, and maybe it has gotten better since last I looked.
We've discussed before about possibly imposing limits on key/value sizes, but 1MB seems very small. I think Thrift is able to handle larger well enough. If gRPC can't handle bigger, that's a bit concerning (in addition to its reliance on protobuf). It seems worth a second look, though. Thanks, Mike! On Fri, Nov 17, 2017 at 9:32 AM Michael Hogue <michael.p.hogu...@gmail.com> wrote: > 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? > > > > > > > > >
