Uploaded image for project: 'Accumulo'
  1. Accumulo
  2. ACCUMULO-4328

Run multiple tablet servers on a single host

    Details

    • Type: Improvement
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.8.0
    • Component/s: scripts, tserver
    • Labels:
      None

      Description

      Modify scripts and necessary code to run multiple tablet servers on a single host.

        Issue Links

          Activity

          Hide
          elserj Josh Elser added a comment -

          (about to be anti-social...)

          Looking at the pull request, you're targeting this for 1.6, Dave Marion? I'd have (at least one) reservation in pulling this into 1.6:

          This really goes against the spirit of our release guidelines. This looks like it would have a huge impact on users. It's hard to quantify this because we have no good guarantees defined on the shell scripts/configuration. However, given that 1.6 is close to EOL, this change doesn't make sense to me for 1.6 or 1.7.

          For a 1.8 or 2.0, I think this would be a nice feature. It would be nice to get some high-level documentation on how it's expected to work before looking at the changes though:

          • How do we track multiple processes in the shell scripts?
          • How do we differentiate multiple tservers on a host internally (inside the master)?
          • What configuration do users need to make to take advantage of this?

          Since you already have a patch put together for this, I'm guessing I'm mostly looking for user manual updates (instead of a design doc).

          Show
          elserj Josh Elser added a comment - (about to be anti-social...) Looking at the pull request, you're targeting this for 1.6, Dave Marion ? I'd have (at least one) reservation in pulling this into 1.6: This really goes against the spirit of our release guidelines. This looks like it would have a huge impact on users. It's hard to quantify this because we have no good guarantees defined on the shell scripts/configuration. However, given that 1.6 is close to EOL, this change doesn't make sense to me for 1.6 or 1.7. For a 1.8 or 2.0, I think this would be a nice feature. It would be nice to get some high-level documentation on how it's expected to work before looking at the changes though: How do we track multiple processes in the shell scripts? How do we differentiate multiple tservers on a host internally (inside the master)? What configuration do users need to make to take advantage of this? Since you already have a patch put together for this, I'm guessing I'm mostly looking for user manual updates (instead of a design doc).
          Hide
          dlmarion Dave Marion added a comment -

          This looks like it would have a huge impact on users.

          By default, it does nothing different than what happens today in 1.6 except for the pid in the log (which could be undone in the logger properties)

          How do we track multiple processes in the shell scripts?

          I backported the pid support, so each tserver instance is named 'tserver-N' and it has an associated pid file.

          How do we differentiate multiple tservers on a host internally (inside the master)?

          By hostname and port, just like today

          What configuration do users need to make to take advantage of this?

          Take a look at the commented example in accumulo-env.sh, and they would need to set the tserver client port to zero.

          Show
          dlmarion Dave Marion added a comment - This looks like it would have a huge impact on users. By default, it does nothing different than what happens today in 1.6 except for the pid in the log (which could be undone in the logger properties) How do we track multiple processes in the shell scripts? I backported the pid support, so each tserver instance is named 'tserver-N' and it has an associated pid file. How do we differentiate multiple tservers on a host internally (inside the master)? By hostname and port, just like today What configuration do users need to make to take advantage of this? Take a look at the commented example in accumulo-env.sh, and they would need to set the tserver client port to zero.
          Hide
          elserj Josh Elser added a comment -

          By default, it does nothing different than what happens today in 1.6 except for the pid in the log (which could be undone in the logger properties)

          It still breaks usability between 1.6.5 and 1.6.6. Things that would work in 1.6.6 will not in 1.6.5 which is the entire spirit of our compatibility statement.

          the pid in the log (which could be undone in the logger properties)

          They don't have separate log files? That sounds nightmareish to debug

          What configuration do users need to make to take advantage of this?

          Take a look at the commented example in accumulo-env.sh, and they would need to set the tserver client port to zero.

          Lots of places like to have stable ports (for security or monitoring reasons). Maybe there's a better approach to be had than resorting to random ports?

          Show
          elserj Josh Elser added a comment - By default, it does nothing different than what happens today in 1.6 except for the pid in the log (which could be undone in the logger properties) It still breaks usability between 1.6.5 and 1.6.6. Things that would work in 1.6.6 will not in 1.6.5 which is the entire spirit of our compatibility statement. the pid in the log (which could be undone in the logger properties) They don't have separate log files? That sounds nightmareish to debug What configuration do users need to make to take advantage of this? Take a look at the commented example in accumulo-env.sh, and they would need to set the tserver client port to zero. Lots of places like to have stable ports (for security or monitoring reasons). Maybe there's a better approach to be had than resorting to random ports?
          Hide
          dlmarion Dave Marion added a comment -

          It still breaks usability between 1.6.5 and 1.6.6. Things that would work in 1.6.6 will not in 1.6.5 which is the entire spirit of our compatibility statement.

          I don't understand how it breaks usability. Can you provide an example?

          They don't have separate log files?

          Correct - not sure how you would do this with Log4J

          Lots of places like to have stable ports (for security or monitoring reasons). Maybe there's a better approach to be had than resorting to random ports?

          Agreed, currently the tserver.client.ports property does not take a list or a range. I think that would be the solution here.

          Show
          dlmarion Dave Marion added a comment - It still breaks usability between 1.6.5 and 1.6.6. Things that would work in 1.6.6 will not in 1.6.5 which is the entire spirit of our compatibility statement. I don't understand how it breaks usability. Can you provide an example? They don't have separate log files? Correct - not sure how you would do this with Log4J Lots of places like to have stable ports (for security or monitoring reasons). Maybe there's a better approach to be had than resorting to random ports? Agreed, currently the tserver.client.ports property does not take a list or a range. I think that would be the solution here.
          Hide
          elserj Josh Elser added a comment -

          It still breaks usability between 1.6.5 and 1.6.6. Things that would work in 1.6.6 will not in 1.6.5 which is the entire spirit of our compatibility statement.

          I don't understand how it breaks usability. Can you provide an example?

          This is a feature which will magically appear in a 6th release of the 1.6 line. All five previous releases in the 1.6 do not have this feature. This is against what we try to do. Users who see this feature in 1.6.6 might think that they can also do it in 1.6.3. This is extremely confusion and against what the versions are supposed to represent. Think about your experiences with configuration properties suddenly appearing in a .Z (of an x.y.z version string) in Hadoop. How jarring would that be to you if 2.6.4 had something that 2.6.1 didn't?

          They don't have separate log files?

          Correct - not sure how you would do this with Log4J

          I think this would be pretty important to figure out. Not having separate log files per daemon would be very strange to try to explain.

          Show
          elserj Josh Elser added a comment - It still breaks usability between 1.6.5 and 1.6.6. Things that would work in 1.6.6 will not in 1.6.5 which is the entire spirit of our compatibility statement. I don't understand how it breaks usability. Can you provide an example? This is a feature which will magically appear in a 6th release of the 1.6 line. All five previous releases in the 1.6 do not have this feature. This is against what we try to do. Users who see this feature in 1.6.6 might think that they can also do it in 1.6.3. This is extremely confusion and against what the versions are supposed to represent. Think about your experiences with configuration properties suddenly appearing in a .Z (of an x.y.z version string) in Hadoop. How jarring would that be to you if 2.6.4 had something that 2.6.1 didn't? They don't have separate log files? Correct - not sure how you would do this with Log4J I think this would be pretty important to figure out. Not having separate log files per daemon would be very strange to try to explain.
          Hide
          dlmarion Dave Marion added a comment -

          This is against what we try to do. Users who see this feature in 1.6.6 might think that they can also do it in 1.6.3.

          If you are referencing our versioning scheme (semver), then it's technically based upon the public API. Our public API is documented in the README and I don't believe any of my changes are in the public API. In a general sense I agree with what you are saying, but I believe that I have provided this in a way which is backwards compatible as there is no change to the user experience unless you enable it.

          Show
          dlmarion Dave Marion added a comment - This is against what we try to do. Users who see this feature in 1.6.6 might think that they can also do it in 1.6.3. If you are referencing our versioning scheme (semver), then it's technically based upon the public API. Our public API is documented in the README and I don't believe any of my changes are in the public API. In a general sense I agree with what you are saying, but I believe that I have provided this in a way which is backwards compatible as there is no change to the user experience unless you enable it.
          Hide
          dlmarion Dave Marion added a comment -

          How jarring would that be to you if 2.6.4 had something that 2.6.1 didn't?

          You mean like https://issues.apache.org/jira/browse/HDFS-7694? Yes, I went and looked for one

          Show
          dlmarion Dave Marion added a comment - How jarring would that be to you if 2.6.4 had something that 2.6.1 didn't? You mean like https://issues.apache.org/jira/browse/HDFS-7694? Yes, I went and looked for one
          Hide
          etcoleman Ed Coleman added a comment -

          Upfront, I'm neutral on this and could go either way - with the caveat that going from 1.6.x to 1.6.6 with this capability does not change any behavior if the feature is not enabled. And that would include needing to modify a current user script in any way. If I can use a 1.6.x config and run it with 1.6.6 without needing to change anything, well, maybe. I'm less worried about going backward, but we would want it documented clearly so that people know what to expect if the needed to roll back and were counting on this.

          Random ports bother me. If there is an option to assign a port, or default to a random one if you don't care, okay - if I can only use a random port, that seems to be a problem if we try to be more container friendly as well as port blocking considerations.

          The big question that I have is, even if you could do this, would you want to? Are there any performance improvements running multiple tservers vs increasing thread counts and memory on a single tserver? I don't think we are normally CPU bound, and multiple tservers are going to be contending for the same IO bandwidth. If we had a benchmark where this did show substantial improvement, then maybe its okay for the 1.6 line. If we don't have that or the time to evaluate it, then 1.7+ may be a better option so that we don't get into a case where - sure its possible - but don't ever do that because A, B ... Z in 1.6.6, use 1.7.x where we fixed that...
          .

          Show
          etcoleman Ed Coleman added a comment - Upfront, I'm neutral on this and could go either way - with the caveat that going from 1.6.x to 1.6.6 with this capability does not change any behavior if the feature is not enabled. And that would include needing to modify a current user script in any way. If I can use a 1.6.x config and run it with 1.6.6 without needing to change anything, well, maybe. I'm less worried about going backward, but we would want it documented clearly so that people know what to expect if the needed to roll back and were counting on this. Random ports bother me. If there is an option to assign a port, or default to a random one if you don't care, okay - if I can only use a random port, that seems to be a problem if we try to be more container friendly as well as port blocking considerations. The big question that I have is, even if you could do this, would you want to? Are there any performance improvements running multiple tservers vs increasing thread counts and memory on a single tserver? I don't think we are normally CPU bound, and multiple tservers are going to be contending for the same IO bandwidth. If we had a benchmark where this did show substantial improvement, then maybe its okay for the 1.6 line. If we don't have that or the time to evaluate it, then 1.7+ may be a better option so that we don't get into a case where - sure its possible - but don't ever do that because A, B ... Z in 1.6.6, use 1.7.x where we fixed that... .
          Hide
          dlmarion Dave Marion added a comment -

          ...with the caveat that going from 1.6.x to 1.6.6 with this capability does not change any behavior if the feature is not enabled. And that would include needing to modify a current user script in any way.

          I believe this to be the case, that you should not have to change anything.

          Random ports bother me. If there is an option to assign a port, or default to a random one if you don't care, okay - if I can only use a random port, that seems to be a problem if we try to be more container friendly as well as port blocking considerations.

          I agree that random ports may be an issue, but its an issue that predates this JIRA. I feel that if we are going to modify tserver.port.client to take a list or range of values instead of 1 value for the purposes that have been stated, then that should be a separate JIRA. However, for the purposes of this issue, if someone wants to use this feature, then they are also choosing to deal with random ports.

          The big question that I have is, even if you could do this, would you want to?

          I don't have any specific evidence to share, but in talking with Keith Turner he expressed an interest in this feature. Maybe he can give more specifics. I will say that one way to scale Accumulo is to add more tablet servers, and just because you have saturated one tablet server does not mean that you have saturated the disk or network bandwidth of the host on which it's running.

          Show
          dlmarion Dave Marion added a comment - ...with the caveat that going from 1.6.x to 1.6.6 with this capability does not change any behavior if the feature is not enabled. And that would include needing to modify a current user script in any way. I believe this to be the case, that you should not have to change anything. Random ports bother me. If there is an option to assign a port, or default to a random one if you don't care, okay - if I can only use a random port, that seems to be a problem if we try to be more container friendly as well as port blocking considerations. I agree that random ports may be an issue, but its an issue that predates this JIRA. I feel that if we are going to modify tserver.port.client to take a list or range of values instead of 1 value for the purposes that have been stated, then that should be a separate JIRA. However, for the purposes of this issue, if someone wants to use this feature, then they are also choosing to deal with random ports. The big question that I have is, even if you could do this, would you want to? I don't have any specific evidence to share, but in talking with Keith Turner he expressed an interest in this feature. Maybe he can give more specifics. I will say that one way to scale Accumulo is to add more tablet servers, and just because you have saturated one tablet server does not mean that you have saturated the disk or network bandwidth of the host on which it's running.
          Hide
          dlmarion Dave Marion added a comment -

          Josh Elser Ed Coleman Would re-basing this PR against 1.7 be a sufficient compromise?

          Show
          dlmarion Dave Marion added a comment - Josh Elser Ed Coleman Would re-basing this PR against 1.7 be a sufficient compromise?
          Hide
          elserj Josh Elser added a comment -

          The big question that I have is, even if you could do this, would you want to? Are there any performance improvements running multiple tservers vs increasing thread counts and memory on a single tserver? I don't think we are normally CPU bound, and multiple tservers are going to be contending for the same IO bandwidth. If we had a benchmark where this did show substantial improvement, then maybe its okay for the 1.6 line. If we don't have that or the time to evaluate it, then 1.7+ may be a better option so that we don't get into a case where - sure its possible - but don't ever do that because A, B ... Z in 1.6.6, use 1.7.x where we fixed that...

          I think Adam Fuchs did some sort of benchmark a while back which showed some promise, but that was, IIRC, related to contention in rolling WALs – something that Eric Newton made better with ACCUMULO-3423 in 1.8. Good benchmarks to understand the cases when this would have performance benefits would be great documentation to include.

          I agree that random ports may be an issue, but its an issue that predates this JIRA.

          Yes and no, IMO. This is formalizing the ability to run multiple TServers as a "feature" which means it needs to be figured out.

          Would re-basing this PR against 1.7 be a sufficient compromise?

          I'm a little less worried against 1.7, but am still not be in favor of it. I'd like to hear what others have to say before I blindly -1 it. The only difference with my complaints with it landing in 1.7 instead of 1.6 is that we have 4 fewer point-releases on 1.7 than 1.6, but that's still two releases which would have different semantics. Keith Turner, Sean Busbey, you both often have good strong opinions on compatibility – a bit of your time to provide some opinions would be appreciated.

          Show
          elserj Josh Elser added a comment - The big question that I have is, even if you could do this, would you want to? Are there any performance improvements running multiple tservers vs increasing thread counts and memory on a single tserver? I don't think we are normally CPU bound, and multiple tservers are going to be contending for the same IO bandwidth. If we had a benchmark where this did show substantial improvement, then maybe its okay for the 1.6 line. If we don't have that or the time to evaluate it, then 1.7+ may be a better option so that we don't get into a case where - sure its possible - but don't ever do that because A, B ... Z in 1.6.6, use 1.7.x where we fixed that... I think Adam Fuchs did some sort of benchmark a while back which showed some promise, but that was, IIRC, related to contention in rolling WALs – something that Eric Newton made better with ACCUMULO-3423 in 1.8. Good benchmarks to understand the cases when this would have performance benefits would be great documentation to include. I agree that random ports may be an issue, but its an issue that predates this JIRA. Yes and no, IMO. This is formalizing the ability to run multiple TServers as a "feature" which means it needs to be figured out. Would re-basing this PR against 1.7 be a sufficient compromise? I'm a little less worried against 1.7, but am still not be in favor of it. I'd like to hear what others have to say before I blindly -1 it. The only difference with my complaints with it landing in 1.7 instead of 1.6 is that we have 4 fewer point-releases on 1.7 than 1.6, but that's still two releases which would have different semantics. Keith Turner , Sean Busbey , you both often have good strong opinions on compatibility – a bit of your time to provide some opinions would be appreciated.
          Hide
          dlmarion Dave Marion added a comment -

          This is formalizing the ability to run multiple TServers as a "feature" which means it needs to be figured out.

          I'm a little confused as you modified the administration guide in 1.6.5 to document how to run multiple tablet servers per host for ACCUMULO-4072. This isn't a new concept, this change just makes it easier on the user.

          Show
          dlmarion Dave Marion added a comment - This is formalizing the ability to run multiple TServers as a "feature" which means it needs to be figured out. I'm a little confused as you modified the administration guide in 1.6.5 to document how to run multiple tablet servers per host for ACCUMULO-4072 . This isn't a new concept, this change just makes it easier on the user.
          Hide
          elserj Josh Elser added a comment -

          That's fair. I forgot I wrote that up. My comment was more about how crappy it was to use (race conditions in starting multiple instances on a host, the inability to manage them all). In the end, I still think there's a bit more we could do here in the name of usability (and production necessity) too.

          Show
          elserj Josh Elser added a comment - That's fair. I forgot I wrote that up. My comment was more about how crappy it was to use (race conditions in starting multiple instances on a host, the inability to manage them all). In the end, I still think there's a bit more we could do here in the name of usability (and production necessity) too.
          Hide
          busbey Sean Busbey added a comment -

          Hadoop is a terrible example to look at, because our versioning there is a mess. Surprising changes regularly show up in double-dot releases and changes that can only be undone with a system rollback happen on single-dot releases. For example I had to argue against changes to the datanode's underlying filesystem layout on a double-dot release recently.

          I personally wouldn't want to see this in a 1.6 or 1.7 release for largely the same reasons Josh states. Changing basics around how we do process management on a double-dot release is tempting trouble. It's not this particular PR's problem, but we have essentially no testing around our scripts so any verification of how 'safe' changes like this are essentially come down to some subset of us working through them manually with ill-defined criteria. But I agree with Dave that this kind of change would not violate the letter of our versioning policy, so I wouldn't -1 on principle. If problems showed up after we had a 1.6.z release that contained it I would, however, then strongly advocate for reverting it in later 1.6 releases using the same 'not the public API' argument.

          Aren't we getting ready to have a 1.8 release soon? What's so pressing about this particular new feature that means we should introduce risk in our established lines rather than roll forward with more minor releases?

          The lack of user-facing docs on what can be expected from this feature, when folks should use it, how folks should use it, etc cause me concern. I get that we pretty regularly have an issue with these kind of "finishing touches" on feature in Accumulo, but it's particularly troublesome to me when these kinds of 'in-the-know' things show up in maintenance releases.

          I'd also strongly prefer having the different tserver instances log to distinct files, regardless of what version this lands in. I get that I can use post-processing to figure out which lines correspond to a given process, but I'm skeptical of log4j's ability to efficiently and safely have multiple processes share a log file. This should be doable with a log4j configs since we control the filename via a classpath config file. I don't have strong feelings on how we go about doing that, wether it's example config files that show making a config-per-expected-process (preferably referenced/explained in the user manual) or a parameter in a single log4j config that the launching script sets via a system property.

          Show
          busbey Sean Busbey added a comment - Hadoop is a terrible example to look at, because our versioning there is a mess. Surprising changes regularly show up in double-dot releases and changes that can only be undone with a system rollback happen on single-dot releases. For example I had to argue against changes to the datanode's underlying filesystem layout on a double-dot release recently. I personally wouldn't want to see this in a 1.6 or 1.7 release for largely the same reasons Josh states. Changing basics around how we do process management on a double-dot release is tempting trouble. It's not this particular PR's problem, but we have essentially no testing around our scripts so any verification of how 'safe' changes like this are essentially come down to some subset of us working through them manually with ill-defined criteria. But I agree with Dave that this kind of change would not violate the letter of our versioning policy, so I wouldn't -1 on principle. If problems showed up after we had a 1.6.z release that contained it I would, however, then strongly advocate for reverting it in later 1.6 releases using the same 'not the public API' argument. Aren't we getting ready to have a 1.8 release soon? What's so pressing about this particular new feature that means we should introduce risk in our established lines rather than roll forward with more minor releases? The lack of user-facing docs on what can be expected from this feature, when folks should use it, how folks should use it, etc cause me concern. I get that we pretty regularly have an issue with these kind of "finishing touches" on feature in Accumulo, but it's particularly troublesome to me when these kinds of 'in-the-know' things show up in maintenance releases. I'd also strongly prefer having the different tserver instances log to distinct files, regardless of what version this lands in. I get that I can use post-processing to figure out which lines correspond to a given process, but I'm skeptical of log4j's ability to efficiently and safely have multiple processes share a log file. This should be doable with a log4j configs since we control the filename via a classpath config file. I don't have strong feelings on how we go about doing that, wether it's example config files that show making a config-per-expected-process (preferably referenced/explained in the user manual) or a parameter in a single log4j config that the launching script sets via a system property.
          Hide
          kturner Keith Turner added a comment -

          In general I think bug fix releases with compatibility caveats are a bad thing over time. This can lead to a very confusing user experience. I think these caveats are worse the further a user is away from directly using Accumulo. For users using Accumulo as part of a stack, they primarily interact with the top of the stack (software built on top of Accumulo). When someone is trying to use something like Geowave, its nice to know that version 1.X.ANY of Geowave works with Accumulo 1.6.ANY. Ideally a user of something like Geowave could move between the bug fix release of Hadoop, Accumulo, and Zookeeper w/o issue. The stories about Hadoop in this issue make me cringe, but there is nothing we can do about that. I would hope the incremental decision we make in the short term also make sense in the long term. If we fast forward a few years and look at all of the 1.7.X release notes, hopefully it looks very orderly and sane.

          Recently there was some major issue with Zookeeper 3.4.7. When the issue was discovered the remedy was for users to move back to 3.4.6 until 3.4.8 was released. Its really nice to have that level of flexibility w/ bug fix releases, the ability to move in both directions w/o worry.

          Also I am not a big fan of one off exceptions, because they can be time sinks (like me currently sharing my opinions, that I am not sure anyone will fully read.. I am doing my best to keep it short and to the point). Personally I would rather drop it in the latest minor release. A really strong case needs to be made for exceptions. Like in this case there does not seem to be performance numbers. Also the implementation (using PIDs in log files) has raised concern. Seem like these issues should be addressed before we consider putting this in a bug fix release. I am going to look into the file per tserver issue when I look at the PR (I did this locally once, where each tserver had its own log file).

          I am excited about this feature. I tend to think multiple tservers can perform much better, simply because when a node had oodles of disk and cores there is no way a single walog can utilize all of that capacity. However I think that premise needs to be verified and ensure there are not unforeseen issues with attaining higher utilization.

          Show
          kturner Keith Turner added a comment - In general I think bug fix releases with compatibility caveats are a bad thing over time. This can lead to a very confusing user experience. I think these caveats are worse the further a user is away from directly using Accumulo. For users using Accumulo as part of a stack, they primarily interact with the top of the stack (software built on top of Accumulo). When someone is trying to use something like Geowave, its nice to know that version 1.X.ANY of Geowave works with Accumulo 1.6.ANY. Ideally a user of something like Geowave could move between the bug fix release of Hadoop, Accumulo, and Zookeeper w/o issue. The stories about Hadoop in this issue make me cringe, but there is nothing we can do about that. I would hope the incremental decision we make in the short term also make sense in the long term. If we fast forward a few years and look at all of the 1.7.X release notes, hopefully it looks very orderly and sane. Recently there was some major issue with Zookeeper 3.4.7. When the issue was discovered the remedy was for users to move back to 3.4.6 until 3.4.8 was released. Its really nice to have that level of flexibility w/ bug fix releases, the ability to move in both directions w/o worry. Also I am not a big fan of one off exceptions, because they can be time sinks (like me currently sharing my opinions, that I am not sure anyone will fully read.. I am doing my best to keep it short and to the point). Personally I would rather drop it in the latest minor release. A really strong case needs to be made for exceptions. Like in this case there does not seem to be performance numbers. Also the implementation (using PIDs in log files) has raised concern. Seem like these issues should be addressed before we consider putting this in a bug fix release. I am going to look into the file per tserver issue when I look at the PR (I did this locally once, where each tserver had its own log file). I am excited about this feature. I tend to think multiple tservers can perform much better, simply because when a node had oodles of disk and cores there is no way a single walog can utilize all of that capacity. However I think that premise needs to be verified and ensure there are not unforeseen issues with attaining higher utilization.
          Hide
          dlmarion Dave Marion added a comment -

          I closed my PR against 1.6.x for this and am porting it for 1.8.x. In testing locally I ran across ACCUMULO-4329, which blocks me from testing further for now.

          Show
          dlmarion Dave Marion added a comment - I closed my PR against 1.6.x for this and am porting it for 1.8.x. In testing locally I ran across ACCUMULO-4329 , which blocks me from testing further for now.
          Hide
          dlmarion Dave Marion added a comment -

          PR against 1.8 has been opened.

          Show
          dlmarion Dave Marion added a comment - PR against 1.8 has been opened.
          Hide
          elserj Josh Elser added a comment -

          In testing locally I ran across ACCUMULO-4329, which blocks me from testing further for now.

          PS, you can set replication.receipt.service.port=0 in accumulo-site as a workaround (if you didn't come to that on your own already)

          Show
          elserj Josh Elser added a comment - In testing locally I ran across ACCUMULO-4329 , which blocks me from testing further for now. PS, you can set replication.receipt.service.port=0 in accumulo-site as a workaround (if you didn't come to that on your own already)
          Hide
          etcoleman Ed Coleman added a comment -

          Dave Marion I concur with targeting this to 1.8. I would have had similar issues that Keith highlighted. You are doing a lot of work on this and I believe that you are on the right track. I'd rather see us take the time now to make sure that this is something we can endorse without reservations - even if that pushes the 1.8 release back a little bit. I would not want to rush and settle for something that we would have to live with if we can avoid it by spending a little more time now,

          Show
          etcoleman Ed Coleman added a comment - Dave Marion I concur with targeting this to 1.8. I would have had similar issues that Keith highlighted. You are doing a lot of work on this and I believe that you are on the right track. I'd rather see us take the time now to make sure that this is something we can endorse without reservations - even if that pushes the 1.8 release back a little bit. I would not want to rush and settle for something that we would have to live with if we can avoid it by spending a little more time now,
          Hide
          elserj Josh Elser added a comment -

          PR against 1.8 has been opened.

          Thanks, Dave Marion. I appreciate you switching the target version. I know it put more work on you.

          Show
          elserj Josh Elser added a comment - PR against 1.8 has been opened. Thanks, Dave Marion . I appreciate you switching the target version. I know it put more work on you.

            People

            • Assignee:
              dlmarion Dave Marion
              Reporter:
              dlmarion Dave Marion
            • Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - 0h
                0h
                Logged:
                Time Spent - 6h
                6h

                  Development