[GitHub] ctubbsii commented on issue #313: ACCUMULO-4726 Add Value.contentEquals(byte[]) method
ctubbsii commented on issue #313: ACCUMULO-4726 Add Value.contentEquals(byte[]) method URL: https://github.com/apache/accumulo/pull/313#issuecomment-340135372 Updated with javadoc and since tag on new method. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (ACCUMULO-4714) Create landing page for new developers
[ https://issues.apache.org/jira/browse/ACCUMULO-4714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16223176#comment-16223176 ] Mark Owens commented on ACCUMULO-4714: -- That was my thought as well. I hope to organize the information that I have repeatedly referred back to as I’ve gotten started with the project. I’ll definitely week out assistance as I go along. > Create landing page for new developers > -- > > Key: ACCUMULO-4714 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4714 > Project: Accumulo > Issue Type: Improvement > Components: website >Reporter: Michael Miller >Assignee: Mark Owens > > The website has a lot of good information for contributing to Accumulo but it > is scattered across multiple pages. There is no clear, concise page that can > be sent as a link to developers interested in committing to the project. I > feel like this is a turn off for someone who is interested in contributing to > Accumulo. > This page would be a good place but it is just a bunch of links: > https://accumulo.apache.org/contributor/ > As a recent newcomer I would tend to go here: > https://accumulo.apache.org/contributor/source > But this page is confusing. The first instructions you get (after more > links) explain how to build the website. Then when you get to the developers > guide the the very first thing is a paragraph about activating the Thrift > profile. While this information is all very useful, the first 2 scenarios > are edge cases of development and it does not ease a new developer into > writing code for Accumulo. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
Accumulo-Master - Build # 2173 - Still Failing
The Apache Jenkins build system has built Accumulo-Master (build #2173) Status: Still Failing Check console output at https://builds.apache.org/job/Accumulo-Master/2173/ to view the results.
[GitHub] keith-turner commented on issue #315: ACCUMULO-4731 Improve exception handling if a key encryption key cannot be loaded
keith-turner commented on issue #315: ACCUMULO-4731 Improve exception handling if a key encryption key cannot be loaded URL: https://github.com/apache/accumulo/pull/315#issuecomment-340059124 @PircDef how did you generate the binary kek files in resources? If it all possible it would be best if the test generated these. One possibility is to gen them in target dir, I can dig up some test code that shows how to get the target dir in a test if you are interested. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] keith-turner commented on a change in pull request #315: ACCUMULO-4731 Improve exception handling if a key encryption key cannot be loaded
keith-turner commented on a change in pull request #315: ACCUMULO-4731 Improve
exception handling if a key encryption key cannot be loaded
URL: https://github.com/apache/accumulo/pull/315#discussion_r147475074
##
File path:
core/src/main/java/org/apache/accumulo/core/security/crypto/CachingHDFSSecretKeyEncryptionStrategy.java
##
@@ -127,26 +128,44 @@ public synchronized void
ensureSecretKeyCacheInitialized(CryptoModuleParameters
pathToKeyName =
Property.CRYPTO_DEFAULT_KEY_STRATEGY_KEY_LOCATION.getDefaultValue();
}
- // TODO ACCUMULO-2530 Ensure volumes a properly supported
+ // TODO ACCUMULO-2530 Ensure volumes are properly supported
Path pathToKey = new Path(pathToKeyName);
FileSystem fs = FileSystem.get(CachedConfiguration.getInstance());
DataInputStream in = null;
+ boolean invalidFile = false;
+ int keyEncryptionKeyLength = 0;
+
try {
if (!fs.exists(pathToKey)) {
initializeKeyEncryptionKey(fs, pathToKey, context);
}
in = fs.open(pathToKey);
-int keyEncryptionKeyLength = in.readInt();
+keyEncryptionKeyLength = in.readInt();
Review comment:
Could also check for negative lengths below, but its seem unnecessary. Are
there any negative numbers that would pass the check below? I don't think so
but not 100% sure since getLen() may return a long and maybe there is some
weird case I am missing with long vs int.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] keith-turner commented on a change in pull request #315: ACCUMULO-4731 Improve exception handling if a key encryption key cannot be loaded
keith-turner commented on a change in pull request #315: ACCUMULO-4731 Improve
exception handling if a key encryption key cannot be loaded
URL: https://github.com/apache/accumulo/pull/315#discussion_r147475074
##
File path:
core/src/main/java/org/apache/accumulo/core/security/crypto/CachingHDFSSecretKeyEncryptionStrategy.java
##
@@ -127,26 +128,44 @@ public synchronized void
ensureSecretKeyCacheInitialized(CryptoModuleParameters
pathToKeyName =
Property.CRYPTO_DEFAULT_KEY_STRATEGY_KEY_LOCATION.getDefaultValue();
}
- // TODO ACCUMULO-2530 Ensure volumes a properly supported
+ // TODO ACCUMULO-2530 Ensure volumes are properly supported
Path pathToKey = new Path(pathToKeyName);
FileSystem fs = FileSystem.get(CachedConfiguration.getInstance());
DataInputStream in = null;
+ boolean invalidFile = false;
+ int keyEncryptionKeyLength = 0;
+
try {
if (!fs.exists(pathToKey)) {
initializeKeyEncryptionKey(fs, pathToKey, context);
}
in = fs.open(pathToKey);
-int keyEncryptionKeyLength = in.readInt();
+keyEncryptionKeyLength = in.readInt();
Review comment:
Could also check for negaive lengths below, but its seem unnecessary. Are
there any negative numbers that would pass the check below? I don't think so
but not 100% sure since getLen() may return a long and maybe there is some
weird case I am missing with long vs int.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] keith-turner commented on a change in pull request #313: ACCUMULO-4726 Add Value.contentEquals(byte[]) method
keith-turner commented on a change in pull request #313: ACCUMULO-4726 Add
Value.contentEquals(byte[]) method
URL: https://github.com/apache/accumulo/pull/313#discussion_r147470769
##
File path: core/src/main/java/org/apache/accumulo/core/data/Value.java
##
@@ -242,16 +242,16 @@ public int compareTo(final byte[] that) {
@Override
public boolean equals(Object right_obj) {
-// compare with byte[] for backwards compatibility, but this is generally
a pretty bad practice
-if (right_obj instanceof byte[]) {
- return compareTo((byte[]) right_obj) == 0;
Review comment:
Also since this class lacks javadoc, the current impl violates the javadoc
from the parent class.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] keith-turner commented on a change in pull request #313: ACCUMULO-4726 Add Value.contentEquals(byte[]) method
keith-turner commented on a change in pull request #313: ACCUMULO-4726 Add
Value.contentEquals(byte[]) method
URL: https://github.com/apache/accumulo/pull/313#discussion_r147469647
##
File path: core/src/main/java/org/apache/accumulo/core/data/Value.java
##
@@ -242,16 +242,16 @@ public int compareTo(final byte[] that) {
@Override
public boolean equals(Object right_obj) {
-// compare with byte[] for backwards compatibility, but this is generally
a pretty bad practice
-if (right_obj instanceof byte[]) {
- return compareTo((byte[]) right_obj) == 0;
-}
if (right_obj instanceof Value) {
return compareTo(right_obj) == 0;
}
return false;
}
+ public boolean contentEquals(byte[] right_obj) {
Review comment:
Need javadoc with since tag
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] keith-turner commented on a change in pull request #313: ACCUMULO-4726 Add Value.contentEquals(byte[]) method
keith-turner commented on a change in pull request #313: ACCUMULO-4726 Add
Value.contentEquals(byte[]) method
URL: https://github.com/apache/accumulo/pull/313#discussion_r147469405
##
File path: core/src/main/java/org/apache/accumulo/core/data/Value.java
##
@@ -242,16 +242,16 @@ public int compareTo(final byte[] that) {
@Override
public boolean equals(Object right_obj) {
-// compare with byte[] for backwards compatibility, but this is generally
a pretty bad practice
-if (right_obj instanceof byte[]) {
- return compareTo((byte[]) right_obj) == 0;
Review comment:
oh, if the change is made its nice the release notes can be edited now.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] keith-turner commented on a change in pull request #313: ACCUMULO-4726 Add Value.contentEquals(byte[]) method
keith-turner commented on a change in pull request #313: ACCUMULO-4726 Add
Value.contentEquals(byte[]) method
URL: https://github.com/apache/accumulo/pull/313#discussion_r147469254
##
File path: core/src/main/java/org/apache/accumulo/core/data/Value.java
##
@@ -242,16 +242,16 @@ public int compareTo(final byte[] that) {
@Override
public boolean equals(Object right_obj) {
-// compare with byte[] for backwards compatibility, but this is generally
a pretty bad practice
-if (right_obj instanceof byte[]) {
- return compareTo((byte[]) right_obj) == 0;
Review comment:
I am ok with making this change (w/o the exception), since the behavior was
not documented. Thinking about it some more there are potential negative
consequences with making the change and not making the change. I have no idea
which will be most beneficial overall.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[jira] [Commented] (ACCUMULO-4714) Create landing page for new developers
[ https://issues.apache.org/jira/browse/ACCUMULO-4714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16222635#comment-16222635 ] Michael Miller commented on ACCUMULO-4714: -- [~ctubbsii] That was my thinking... not create new information, but just to gather all the most relevant information for a new contributor in one easy to read page. Thanks for picking this up [~jmark99]! I think this would be a great task for you as you seek out this information :). Feel free to ping the community as well for clarification on whether certain information is useful/relevant or up to date. > Create landing page for new developers > -- > > Key: ACCUMULO-4714 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4714 > Project: Accumulo > Issue Type: Improvement > Components: website >Reporter: Michael Miller >Assignee: Mark Owens > > The website has a lot of good information for contributing to Accumulo but it > is scattered across multiple pages. There is no clear, concise page that can > be sent as a link to developers interested in committing to the project. I > feel like this is a turn off for someone who is interested in contributing to > Accumulo. > This page would be a good place but it is just a bunch of links: > https://accumulo.apache.org/contributor/ > As a recent newcomer I would tend to go here: > https://accumulo.apache.org/contributor/source > But this page is confusing. The first instructions you get (after more > links) explain how to build the website. Then when you get to the developers > guide the the very first thing is a paragraph about activating the Thrift > profile. While this information is all very useful, the first 2 scenarios > are edge cases of development and it does not ease a new developer into > writing code for Accumulo. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (ACCUMULO-4728) Allow tserver to reject migration
[ https://issues.apache.org/jira/browse/ACCUMULO-4728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16222632#comment-16222632 ] Josh Elser commented on ACCUMULO-4728: -- bq. This was observed with a table.classpath.context that was not setup locally in the nodes configuration. Any tablets assigned from that table would fail to load indefinitely. Sorry, let me be more specific. I was hoping to get a specific error message or stacktrace to the problem. Looking for where an exception was thrown so that when someone wants to try to improve this, they can trace the execution flow and see why we don't bubble out of some message :) > Allow tserver to reject migration > - > > Key: ACCUMULO-4728 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4728 > Project: Accumulo > Issue Type: Improvement > Components: tserver >Reporter: Charles Williams >Assignee: Charles Williams >Priority: Minor > > An otherwise well functioning tserver may fail to load a tablet indefinitely > without the master re-assigning the tablet to another tserver. In some cases > the tserver may be miss configured in some way that prevents loading a set of > specific tablets from a specific set of tables. > If the tserver could respond to the master with a failure to load a tablet > and abort the master could then re-assign the tablet somewhere else. In some > instances this could prevent an outage. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (ACCUMULO-4732) No APIs to configure iterators and locality groups for new table
[ https://issues.apache.org/jira/browse/ACCUMULO-4732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16222608#comment-16222608 ] Christopher Tubbs commented on ACCUMULO-4732: - Tagged this as "newbie", because I think it could be done relatively easily by a newcomer. It's too bad we're not using GitHub for issue tracking, because GitHub promotes issues to new developers. It could also be promoted with the DigitalOcean "hacktoberfest" campaign. :/ > No APIs to configure iterators and locality groups for new table > > > Key: ACCUMULO-4732 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4732 > Project: Accumulo > Issue Type: Improvement >Reporter: Keith Turner > Labels: newbie > Fix For: 2.0.0 > > > In Accumulo 1.7 the ability to set table properties at table creation time > was added. For existing tables there are APIs in table operations that allow > setting locality groups and iterators for existing tables. When setting > table properties at table creation time there is not good API for iterators > and locality groups. There should be some way in the API to do this. There > may be other things besides iterators and locality groups that should also be > supported at table creation time. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (ACCUMULO-4732) No APIs to configure iterators and locality groups for new table
[ https://issues.apache.org/jira/browse/ACCUMULO-4732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Tubbs updated ACCUMULO-4732: Labels: newbie (was: ) > No APIs to configure iterators and locality groups for new table > > > Key: ACCUMULO-4732 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4732 > Project: Accumulo > Issue Type: Improvement >Reporter: Keith Turner > Labels: newbie > Fix For: 2.0.0 > > > In Accumulo 1.7 the ability to set table properties at table creation time > was added. For existing tables there are APIs in table operations that allow > setting locality groups and iterators for existing tables. When setting > table properties at table creation time there is not good API for iterators > and locality groups. There should be some way in the API to do this. There > may be other things besides iterators and locality groups that should also be > supported at table creation time. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (ACCUMULO-4731) Improve exception handling if a key encryption key cannot be loaded
[ https://issues.apache.org/jira/browse/ACCUMULO-4731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated ACCUMULO-4731: - Labels: pull-request-available (was: ) > Improve exception handling if a key encryption key cannot be loaded > --- > > Key: ACCUMULO-4731 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4731 > Project: Accumulo > Issue Type: Improvement > Components: tserver >Reporter: Nick Felts >Assignee: Nick Felts >Priority: Minor > Labels: pull-request-available > Fix For: 2.0.0 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (ACCUMULO-4729) MiniAccumuloCluster should have a Singleton
[
https://issues.apache.org/jira/browse/ACCUMULO-4729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16222605#comment-16222605
]
Jorge Machado commented on ACCUMULO-4729:
-
Yes that was what end up doing.
I have a very small code for that
{code:java}
/**
* Serves as entry point for using MiniAccumulo cluster.
*/
public class SailMiniAccumuloCluster {
private static MiniAccumuloCluster mini;
private SailMiniAccumuloCluster(){}
public static MiniAccumuloCluster getInstance(MiniAccumuloConfig conf)
throws InterruptedException, AccumuloException,
AccumuloSecurityException, IOException
{
if (mini ==null){
mini = new MiniAccumuloCluster(conf);
mini.start();
}
return mini;
}
}
{code}
then the before and after classes just stop it.
But would be nice if we have like a helper were we could extend on
> MiniAccumuloCluster should have a Singleton
> ---
>
> Key: ACCUMULO-4729
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4729
> Project: Accumulo
> Issue Type: New Feature
> Components: mini
>Affects Versions: 1.8.1
>Reporter: Jorge Machado
>Priority: Minor
>
> As developer I would like to have something like
> MiniAccumuloCluster.getInstance()
> That I can share with multiple tests
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] ctubbsii commented on issue #315: ACCUMULO-4731 Improve exception handling if a key encryption key cannot be loaded
ctubbsii commented on issue #315: ACCUMULO-4731 Improve exception handling if a key encryption key cannot be loaded URL: https://github.com/apache/accumulo/pull/315#issuecomment-340012873 For some reason, this PR isn't updating JIRA. I think JIRA integration might be broken again. Mentioning ACCUMULO-4731 should update https://issues.apache.org/jira/browse/ACCUMULO-4731 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Updated] (ACCUMULO-4731) Improve exception handling if a key encryption key cannot be loaded
[ https://issues.apache.org/jira/browse/ACCUMULO-4731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Tubbs updated ACCUMULO-4731: Priority: Minor (was: Critical) Fix Version/s: 2.0.0 Component/s: tserver > Improve exception handling if a key encryption key cannot be loaded > --- > > Key: ACCUMULO-4731 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4731 > Project: Accumulo > Issue Type: Improvement > Components: tserver >Reporter: Nick Felts >Assignee: Nick Felts >Priority: Minor > Fix For: 2.0.0 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (ACCUMULO-4714) Create landing page for new developers
[ https://issues.apache.org/jira/browse/ACCUMULO-4714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16222596#comment-16222596 ] Christopher Tubbs commented on ACCUMULO-4714: - This sounds like a great idea. Even better, if this page can eliminate the need for the other pages with the scattered information. I think much of it is just noise, and makes it harder to find the useful bits. The more we can delete and replace with simple and clear info, the better. > Create landing page for new developers > -- > > Key: ACCUMULO-4714 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4714 > Project: Accumulo > Issue Type: Improvement > Components: website >Reporter: Michael Miller >Assignee: Mark Owens > > The website has a lot of good information for contributing to Accumulo but it > is scattered across multiple pages. There is no clear, concise page that can > be sent as a link to developers interested in committing to the project. I > feel like this is a turn off for someone who is interested in contributing to > Accumulo. > This page would be a good place but it is just a bunch of links: > https://accumulo.apache.org/contributor/ > As a recent newcomer I would tend to go here: > https://accumulo.apache.org/contributor/source > But this page is confusing. The first instructions you get (after more > links) explain how to build the website. Then when you get to the developers > guide the the very first thing is a paragraph about activating the Thrift > profile. While this information is all very useful, the first 2 scenarios > are edge cases of development and it does not ease a new developer into > writing code for Accumulo. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (ACCUMULO-4348) Deprecate KerberosToken constructor that exposes UserGroupInformation
[
https://issues.apache.org/jira/browse/ACCUMULO-4348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16222592#comment-16222592
]
Jorge Machado commented on ACCUMULO-4348:
-
I was working on a client with Kerberos. I think we should just should not
deprecate the replace user.
I just spend two days trying to see where the error is.
what do you think ?
> Deprecate KerberosToken constructor that exposes UserGroupInformation
> -
>
> Key: ACCUMULO-4348
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4348
> Project: Accumulo
> Issue Type: Improvement
> Components: client, core
>Affects Versions: 1.7.2
>Reporter: William Slacum
>Assignee: William Slacum
>Priority: Trivial
> Fix For: 1.8.0
>
> Original Estimate: 10m
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> {{KerberosToken}} works by setting up some metadata about a current user to
> be validated later by when a {{UGIAssumingTransport}} is created. The
> {{public KerberosToken(String principal, File keytab, boolean
> replaceCurrentUser) throws IOException}} constructor leaks out the
> {{UserGroupInformation}} (or a construct with a similar concept of having
> mutable, static variables) dependency, by allowing users to login as a user
> and hold on to their credentials in a place external to the token itself.
> While working on ACCUMULO-4306, I was thinking about whether or not this
> feature/side effect of {{KerberosToken}} made sense. It is a user convenience
> thing, but it's not a big convenience, as logging in as another user isn't
> complicated (via {{UserGroupInformation}} or standard Java methodologies.
> It's also a potential hazard if two threads update the same
> {{UserGroupInformation}} class at the same time.
> Without much convenience and concurrency pitfalls, marking this deprecating
> in 1.8 and removing in 2.0 makes the most sense.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (ACCUMULO-4729) MiniAccumuloCluster should have a Singleton
[ https://issues.apache.org/jira/browse/ACCUMULO-4729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Tubbs updated ACCUMULO-4729: Issue Type: New Feature (was: Bug) > MiniAccumuloCluster should have a Singleton > --- > > Key: ACCUMULO-4729 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4729 > Project: Accumulo > Issue Type: New Feature > Components: mini >Affects Versions: 1.8.1 >Reporter: Jorge Machado >Priority: Minor > > As developer I would like to have something like > MiniAccumuloCluster.getInstance() > That I can share with multiple tests -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (ACCUMULO-4729) MiniAccumuloCluster should have a Singleton
[
https://issues.apache.org/jira/browse/ACCUMULO-4729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16222579#comment-16222579
]
Christopher Tubbs commented on ACCUMULO-4729:
-
There are two ways I've seen MiniAccumuloCluster shared with multiple tests:
1. A JUnit test having a {{@BeforeClass}} section to start the cluster, and an
{{@AfterClass}} section to stop it, with multiple {{@Test}} methods to each run
a test.
2. Using {{accumulo-maven-plugin}} to launch (Mini)Accumulo at the
{{pre-integration-test}} phase of the Maven build lifecycle, and run many tests
during the {{integration-test}} phase, with the {{maven-failsafe-plugin}}, and
then shut down at {{post-integration-test}} just before integration tests are
validated in the {{verify}} phase.
If MiniAccumuloCluster were made to have a singleton, I'm not sure it would be
clear who would be responsible for managing its lifecycle (shutting it down,
starting it, etc.). And, this would be especially weird if we still allowed
{{new MiniAccumuloCluster}}s to be launched separately from this singleton.
That could be confusing.
For your use case, is it possible for you to simple assign {{new
MiniAccumuloCluster}} to a variable, which you share with all your tests? That
seems like the best solution to me.
> MiniAccumuloCluster should have a Singleton
> ---
>
> Key: ACCUMULO-4729
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4729
> Project: Accumulo
> Issue Type: Bug
> Components: mini
>Affects Versions: 1.8.1
>Reporter: Jorge Machado
>Priority: Minor
>
> As developer I would like to have something like
> MiniAccumuloCluster.getInstance()
> That I can share with multiple tests
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (ACCUMULO-4728) Allow tserver to reject migration
[ https://issues.apache.org/jira/browse/ACCUMULO-4728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16222327#comment-16222327 ] Charles Williams commented on ACCUMULO-4728: This was observed with a table.classpath.context that was not setup locally in the nodes configuration. Any tablets assigned from that table would fail to load indefinitely. > Allow tserver to reject migration > - > > Key: ACCUMULO-4728 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4728 > Project: Accumulo > Issue Type: Improvement > Components: tserver >Reporter: Charles Williams >Assignee: Charles Williams >Priority: Minor > > An otherwise well functioning tserver may fail to load a tablet indefinitely > without the master re-assigning the tablet to another tserver. In some cases > the tserver may be miss configured in some way that prevents loading a set of > specific tablets from a specific set of tables. > If the tserver could respond to the master with a failure to load a tablet > and abort the master could then re-assign the tablet somewhere else. In some > instances this could prevent an outage. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
