I'm sure I know some people trying to use Accumulo+HDFS tracing, and it's
going to cause a problem no matter what, because Hadoop and Accumulo aren't
always upgraded at the same time. I just want to make sure it gets better
at some point, if both are sufficiently up-to-date.
Backporting patches to
Ah, that makes more sense. I would be fine with bumping the htrace
dependency to match the most recent version of Hadoop that we support and
not doing a shim layer. We might want to check in with any users who are
using the Accumulo+HDFS tracing to see if this would be a problem for them.
I am not
Github user keith-turner commented on the issue:
https://github.com/apache/accumulo/pull/121
@ShawnWalker I looked over the changes, looks good. Did you test running
stop-here.sh?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHu
Ah, my mistake. I thought it was 2.7 and later. Well, then I guess the
question is whether we should bump to 2.8, then. I'm not a fan of the shim
layer. I'd rather provide support for downstream packagers trying to
backport for HTrace3, if anybody ends up requiring that, than provide a
shim to pres
I'm in favor of bumping our Hadoop version to 2.7. We are already on the
same htrace version as Hadoop 2.7. (The discussion in ACCUMULO-4171 is
relevant to Hadoop 2.8 and later.)
Billie
On Thu, Jul 7, 2016 at 2:20 PM, Christopher wrote:
> Thinking about https://issues.apache.org/jira/browse/ACC
Thinking about https://issues.apache.org/jira/browse/ACCUMULO-4171, I'm of
the opinion that we should probably bump our Hadoop version to 2.7 and
HTrace version to what Hadoop is using, to keep them in sync.
Does anybody disagree?
Github user keith-turner commented on the issue:
https://github.com/apache/accumulo/pull/121
> Indeed, I found this out when I went to implement my idea.
I just noticed that commit. I can look over those changes today. I like
the idea of changing save to an enum.
---
If yo
Github user ShawnWalker commented on the issue:
https://github.com/apache/accumulo/pull/121
> I took a quick look and it seemed a tserver did not know why it was
unloading. It seems like the tserver would need to know why it was unloading so
it could only suspend when being stopped (w
Github user keith-turner commented on the issue:
https://github.com/apache/accumulo/pull/121
> My current thought would be to make unloading a tablet this way suspend
the tablet instead of unassigning
I took a quick look and it seemed a tserver did not know why it was
unloadi
