[DISCUSS] Moving away from Thrift

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

[DISCUSS] Moving away from Thrift

Christopher Tubbs-2
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?
Reply | Threaded
Open this post in threaded view
|

RE: [DISCUSS] Moving away from Thrift

Ed Coleman
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:[hidden email]]
Sent: Thursday, November 16, 2017 11:36 PM
To: accumulo-dev <[hidden email]>
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?

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Moving away from Thrift

Christopher Tubbs-2
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 <[hidden email]> 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:[hidden email]]
> Sent: Thursday, November 16, 2017 11:36 PM
> To: accumulo-dev <[hidden email]>
> 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?
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Moving away from Thrift

Mike Drob-4
Apache projects are highly discouraged from hostile forks of other ASF
projects. I'm not sure if there's a written foundation policy for it or if
it's simply a gentleman's agreement, but I've seen it come up in other
places and it has never been pretty.

Which alternatives are you considering, Christopher? Avro RPC keeps us in
the Apache umbrella. I've seen Accumulo+Kryo work, but it always felt
kludgy. Protobuf has it's own issues.

There may just be no good RPC solution existing today.

Mike

On Thu, Nov 16, 2017, 10:58 PM Christopher <[hidden email]> 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 <[hidden email]> 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:[hidden email]]
> > Sent: Thursday, November 16, 2017 11:36 PM
> > To: accumulo-dev <[hidden email]>
> > 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?
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Moving away from Thrift

Christopher Tubbs-2
On Fri, Nov 17, 2017 at 12:26 AM Mike Drob <[hidden email]> wrote:

> Apache projects are highly discouraged from hostile forks of other ASF
> projects. I'm not sure if there's a written foundation policy for it or if
> it's simply a gentleman's agreement, but I've seen it come up in other
> places and it has never been pretty.
>
> Which alternatives are you considering, Christopher? Avro RPC keeps us in
> the Apache umbrella. I've seen Accumulo+Kryo work, but it always felt
> kludgy. Protobuf has it's own issues.
>
>
I don't really have enough information about any to consider at this point.
The main purpose of this thread is to solicit suggestions for alternatives
to consider. I'm not familiar with Avro RPC. As I understand it, Avro is
serialization (same with Kryo and Protobuf). I think we have tons of
options for serialization, but the main thing Thrift does for us that I
haven't really seen elsewhere is the RPC language definition and
boilerplate network/protocol stuff.


> There may just be no good RPC solution existing today.
>
>
Yeah. That is a concern. :/


> Mike
>
> On Thu, Nov 16, 2017, 10:58 PM Christopher <[hidden email]> 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 <[hidden email]> 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:[hidden email]]
> > > Sent: Thursday, November 16, 2017 11:36 PM
> > > To: accumulo-dev <[hidden email]>
> > > 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?
> > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Moving away from Thrift

Dylan Hutchison-5
I don't know if it is mature yet, but Apache Arrow has an RPC format and
bindings for several languages.  See slide 37+ here:

https://www.slideshare.net/julienledem/the-columnar-roadmap-apache-parquet-and-apache-arrow


Arrow's RPC would be particularly advantageous if the Arrow format were
used throughout Accumulo, but perhaps there is some benefit with just using
Arrow's RPC.

On Thu, Nov 16, 2017 at 9:49 PM, Christopher <[hidden email]> wrote:

> On Fri, Nov 17, 2017 at 12:26 AM Mike Drob <[hidden email]> wrote:
>
> > Apache projects are highly discouraged from hostile forks of other ASF
> > projects. I'm not sure if there's a written foundation policy for it or
> if
> > it's simply a gentleman's agreement, but I've seen it come up in other
> > places and it has never been pretty.
> >
> > Which alternatives are you considering, Christopher? Avro RPC keeps us in
> > the Apache umbrella. I've seen Accumulo+Kryo work, but it always felt
> > kludgy. Protobuf has it's own issues.
> >
> >
> I don't really have enough information about any to consider at this point.
> The main purpose of this thread is to solicit suggestions for alternatives
> to consider. I'm not familiar with Avro RPC. As I understand it, Avro is
> serialization (same with Kryo and Protobuf). I think we have tons of
> options for serialization, but the main thing Thrift does for us that I
> haven't really seen elsewhere is the RPC language definition and
> boilerplate network/protocol stuff.
>
>
> > There may just be no good RPC solution existing today.
> >
> >
> Yeah. That is a concern. :/
>
>
> > Mike
> >
> > On Thu, Nov 16, 2017, 10:58 PM Christopher <[hidden email]> 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 <[hidden email]>
> 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:[hidden email]]
> > > > Sent: Thursday, November 16, 2017 11:36 PM
> > > > To: accumulo-dev <[hidden email]>
> > > > 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?
> > > >
> > > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Moving away from Thrift

Jorge Machado
In reply to this post by Christopher Tubbs-2
What about https://grpc.io/ ? From Google ?

Jorge Machado


Am 17.11.2017 um 05:50 schrieb Christopher <[hidden email]<mailto:[hidden email]>>:

On Fri, Nov 17, 2017 at 12:26 AM Mike Drob <[hidden email]<mailto:[hidden email]>> wrote:

Apache projects are highly discouraged from hostile forks of other ASF
projects. I'm not sure if there's a written foundation policy for it or if
it's simply a gentleman's agreement, but I've seen it come up in other
places and it has never been pretty.

Which alternatives are you considering, Christopher? Avro RPC keeps us in
the Apache umbrella. I've seen Accumulo+Kryo work, but it always felt
kludgy. Protobuf has it's own issues.


I don't really have enough information about any to consider at this point.
The main purpose of this thread is to solicit suggestions for alternatives
to consider. I'm not familiar with Avro RPC. As I understand it, Avro is
serialization (same with Kryo and Protobuf). I think we have tons of
options for serialization, but the main thing Thrift does for us that I
haven't really seen elsewhere is the RPC language definition and
boilerplate network/protocol stuff.


There may just be no good RPC solution existing today.


Yeah. That is a concern. :/


Mike

On Thu, Nov 16, 2017, 10:58 PM Christopher <[hidden email]<mailto:[hidden email]>> 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 <[hidden email]<mailto:[hidden email]>> 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:[hidden email]]
Sent: Thursday, November 16, 2017 11:36 PM
To: accumulo-dev <[hidden email]<mailto:[hidden email]>>
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?




Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Moving away from Thrift

Jonathan Wonders
I have had pleasant experiences with grpc for several little projects.  The
grpc project is explicit about stable and experimental apis.  There are
however still a number of useful features that are considered experimental.

Since grpc supports async requests over TLS channels it would make it much
more natural to add async apis for both scanning and writing.  I've been
working on a little side project to explore what is possible today but got
ran into challenges due to thrift not supporting TLS for nonblocking
clients.  I think grpc could lead to the possibility of eliminating some
thread pools within the accumulo client.

Another benefit is that it uses a standardized protocol (HTTP/2) underneath.

It is the best alternative to thrift that I'm aware of for general purpose
rpc/ipc.  That being said, it would be a serious undertaking to swap out
thrift for anything else.

--Jonathan

On Nov 17, 2017 2:51 AM, "Jorge Machado" <[hidden email]>
wrote:

> What about https://grpc.io/ ? From Google ?
>
> Jorge Machado
>
>
> Am 17.11.2017 um 05:50 schrieb Christopher <[hidden email]<mailto:ct
> [hidden email]>>:
>
> On Fri, Nov 17, 2017 at 12:26 AM Mike Drob <[hidden email]<mailto:mdrob
> @apache.org>> wrote:
>
> Apache projects are highly discouraged from hostile forks of other ASF
> projects. I'm not sure if there's a written foundation policy for it or if
> it's simply a gentleman's agreement, but I've seen it come up in other
> places and it has never been pretty.
>
> Which alternatives are you considering, Christopher? Avro RPC keeps us in
> the Apache umbrella. I've seen Accumulo+Kryo work, but it always felt
> kludgy. Protobuf has it's own issues.
>
>
> I don't really have enough information about any to consider at this point.
> The main purpose of this thread is to solicit suggestions for alternatives
> to consider. I'm not familiar with Avro RPC. As I understand it, Avro is
> serialization (same with Kryo and Protobuf). I think we have tons of
> options for serialization, but the main thing Thrift does for us that I
> haven't really seen elsewhere is the RPC language definition and
> boilerplate network/protocol stuff.
>
>
> There may just be no good RPC solution existing today.
>
>
> Yeah. That is a concern. :/
>
>
> Mike
>
> On Thu, Nov 16, 2017, 10:58 PM Christopher <[hidden email]<mailto:ct
> [hidden email]>> 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 <[hidden email]<mailto:dev
> [hidden email]>> 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:[hidden email]]
> Sent: Thursday, November 16, 2017 11:36 PM
> To: accumulo-dev <[hidden email]<mailto:[hidden email]>>
> 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?
>
>
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Moving away from Thrift

Josh Elser-2
In reply to this post by Christopher Tubbs-2
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" <[hidden email]> 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 <[hidden email]> 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:[hidden email]]
> > Sent: Thursday, November 16, 2017 11:36 PM
> > To: accumulo-dev <[hidden email]>
> > 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?
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Moving away from Thrift

Jorge Machado
Do we have a List of topics with thrift problems ?

Jorge Machado
[hidden email]<mailto:[hidden email]>


Am 17.11.2017 um 13:21 schrieb Josh Elser <[hidden email]<mailto:[hidden email]>>:

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" <[hidden email]<mailto:[hidden email]>> 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 <[hidden email]<mailto:[hidden email]>> 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:[hidden email]]
Sent: Thursday, November 16, 2017 11:36 PM
To: accumulo-dev <[hidden email]<mailto:[hidden email]>>
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?



Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Moving away from Thrift

Michael Hogue
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 <[hidden email]>
wrote:

> Do we have a List of topics with thrift problems ?
>
> Jorge Machado
> [hidden email]<mailto:[hidden email]>
>
>
> Am 17.11.2017 um 13:21 schrieb Josh Elser <[hidden email]<mailto:
> [hidden email]>>:
>
> 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" <[hidden email]<mailto:
> [hidden email]>> 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 <[hidden email]<mailto:
> [hidden email]>> 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:[hidden email]]
> Sent: Thursday, November 16, 2017 11:36 PM
> To: accumulo-dev <[hidden email]<mailto:[hidden email]>>
> 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?
>
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Moving away from Thrift

Sean Busbey
In reply to this post by Josh Elser-2
Similarly, see me on behalf of the HBase PMC prodding Hadoop to make more
maintenance releases.

Let's work out our messaging for "your downstreams ask you to please
release" as well as our offer of help.

On Fri, Nov 17, 2017 at 7:21 AM, Josh Elser <[hidden email]> wrote:

> 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" <[hidden email]> 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 <[hidden email]> 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:[hidden email]]
> > > Sent: Thursday, November 16, 2017 11:36 PM
> > > To: accumulo-dev <[hidden email]>
> > > 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?
> > >
> > >
> >
>



--
busbey
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Moving away from Thrift

Christopher Tubbs-2
In reply to this post by Josh Elser-2
On Fri, Nov 17, 2017 at 8:21 AM Josh Elser <[hidden email]> wrote:

> Did you offer to make the release? See me with commons-vfs a time back.
>
>
The current issue with Thrift is not the point. The problems we've
encountered with Thrift were was provided as background context only.


> Your proposal seems to me like you're blowing the situation out of
> proportion.
>
>
I haven't proposed we do anything beyond "consider" or "discuss". I don't
think "consider" or "discuss" are "out of proportion", even if Thrift had
zero problems.


> On Nov 16, 2017 23:58, "Christopher" <[hidden email]> 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 <[hidden email]> 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:[hidden email]]
> > > Sent: Thursday, November 16, 2017 11:36 PM
> > > To: accumulo-dev <[hidden email]>
> > > 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?
> > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Moving away from Thrift

Christopher Tubbs-2
In reply to this post by Michael Hogue
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 <[hidden email]>
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 <[hidden email]
> >
> wrote:
>
> > Do we have a List of topics with thrift problems ?
> >
> > Jorge Machado
> > [hidden email]<mailto:[hidden email]>
> >
> >
> > Am 17.11.2017 um 13:21 schrieb Josh Elser <[hidden email]<mailto:
> > [hidden email]>>:
> >
> > 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" <[hidden email]<mailto:
> > [hidden email]>> 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 <[hidden email]<mailto:
> > [hidden email]>> 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:[hidden email]]
> > Sent: Thursday, November 16, 2017 11:36 PM
> > To: accumulo-dev <[hidden email]<mailto:[hidden email]
> >>
> > 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?
> >
> >
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Moving away from Thrift

Josh Elser-2
In reply to this post by Christopher Tubbs-2


On 11/17/17 10:32 AM, Christopher wrote:
> On Fri, Nov 17, 2017 at 8:21 AM Josh Elser<[hidden email]>  wrote:
>
>> Did you offer to make the release? See me with commons-vfs a time back.
>>
>>
> The current issue with Thrift is not the point. The problems we've
> encountered with Thrift were was provided as background context only.

I seriously think you are avoiding all of the good that Thrift provides
us for the sake of a platform to discuss your distaste. Take a look at
the amount of code that makes up Hadoop's or HBase's RPC implementations
and the corresponding (often nasty) bugs that have come up over the years.

There are numerous things which Thrift continues to do very well that
have never become problems for us in Accumulo. Having seen the other
side of the fence, I would happily take Thrift (warts and all) any day
over the alternatives.

>> Your proposal seems to me like you're blowing the situation out of
>> proportion.
>>
>>
> I haven't proposed we do anything beyond "consider" or "discuss". I don't
> think "consider" or "discuss" are "out of proportion", even if Thrift had
> zero problems.

/me blinks. Ok then.
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Moving away from Thrift

Christopher Tubbs-2
On Fri, Nov 17, 2017 at 12:03 PM Josh Elser <[hidden email]> wrote:

>
>
> On 11/17/17 10:32 AM, Christopher wrote:
> > On Fri, Nov 17, 2017 at 8:21 AM Josh Elser<[hidden email]>  wrote:
> >
> >> Did you offer to make the release? See me with commons-vfs a time back.
> >>
> >>
> > The current issue with Thrift is not the point. The problems we've
> > encountered with Thrift were was provided as background context only.
>
> I seriously think you are avoiding all of the good that Thrift provides
> us for the sake of a platform to discuss your distaste. Take a look at
> the amount of code that makes up Hadoop's or HBase's RPC implementations
> and the corresponding (often nasty) bugs that have come up over the years.
>
>
That's really not it. I'm just trying to have a discussion about what
alternatives *might* be better. The answer might be nothing. I'm okay with
that. I just want to discuss as a group.


> There are numerous things which Thrift continues to do very well that
> have never become problems for us in Accumulo. Having seen the other
> side of the fence, I would happily take Thrift (warts and all) any day
> over the alternatives.
>
>
I have not had the luxury of having experience with many alternatives.
Since my intention here is to solicit that kind of perspective, I'd love to
hear more about your experiences with possible alternatives, and where they
might be better or worse than Thrift for Accumulo.


> >> Your proposal seems to me like you're blowing the situation out of
> >> proportion.
> >>
> >>
> > I haven't proposed we do anything beyond "consider" or "discuss". I don't
> > think "consider" or "discuss" are "out of proportion", even if Thrift had
> > zero problems.
>
> /me blinks. Ok then.
>