Skip to content

Conversation

@kevinrr888
Copy link
Member

Closes #3646.
Refactored ScanConsistencyIT to be able to be run standalone. Can now be run as a test or from main.

Closes apache#3646. Refactored ScanConsistencyIT to be able to be run standalone. Can now be run as a test or from main.
checkEquals(stats3.scanned, stats1.scanned);
checkEquals(stats3.verified, stats1.verified);

executor.shutdownNow();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would be good to shutdown this executor in a finally block still.

@kevinrr888
Copy link
Member Author

kevinrr888 commented Dec 11, 2023

Added requested changes:

  • Removed "@ throws Exception" from javadoc. Hopefully fixes build failure from "Checkstyle violations".
  • Shutdown the executor in a finally block
  • Table is now deleted when test is done
  • Check args length using Preconditions.checkArgument()
  • Moved client into try-with-resources block
  • Messages are now logged in debug mode if in testing context, info mode otherwise

*
* @param msg message to be logged
*/
private static void logMessage(String msg) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this necessary? Logging at a relevant level should apply to either context, and con be controlled through normal logging settings to show or suppress levels as desired.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Assumed (based on previous comments) that the message should be logged in debug mode if we are in the testing context, and info mode otherwise. Should this always be log.info?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My reading is that is one possibility. Depending on the frequency of some of the messages, maybe some are debug and others are at info?

Then using log4j configuration can be tuned for the circumstance.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changing everything to info should be fine. The test are already configured to log debug output here, so changing to info would not increase the amount output by the test when running it from maven.

checkEquals(stats3.verified, stats1.verified);
} finally {
executor.shutdownNow();
client.tableOperations().delete(table);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Placing code in a finally block that may throw an exception is tricky. I would not expected shutting down the executor throw an exception, but deleting the table might. If code in the try block throws an exception and code in the finally block throws an exception, then the exception from the try block is lost. Not sure of a good way to improve this though other than something like the following.

try{

} catch(Exception e) {
   // log here in case the finally block also throws an exception
    log.error(e.getMessage(),e);
    throw e;
} finally {
   executor.shutdownNow();
   client.tableOperations().delete(table);
}

Copy link
Member Author

@kevinrr888 kevinrr888 Dec 11, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah I see. Could I also just move the deletion of the table into the above try block?

try {
...
client.tableOperations().delete(table);
} finally {
executor.shutdownNow();
}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah putting the delete inside the try seems fine. If the test fails it will not delete the table which may be useful for debugging anyway.

@dlmarion
Copy link
Contributor

dlmarion commented Dec 11, 2023

The same can be achieved using the instructions here. Just curious, why would we need this?

@keith-turner
Copy link
Contributor

The same can be achieved using the instructions here. Just curious, why would we need this?

We may not, I had forgotten about that, wonder if the following work

  1. Setup accumulo in uno
  2. copy test jar to uno lib dir, this is needed because the test has server side code it runs
  3. restart accumulo
  4. run test using mvn passing in uno accumulo props file

If it does work may still want some of the changes in this PR like deleting the table.

@keith-turner
Copy link
Contributor

When running this test manually against an existing instance, would like to be able to adjust this sleep. Would like to be able to run this test against an uno instance for hours.

@dlmarion
Copy link
Contributor

See this for running an IT against an existing instance. Caveat: I've never tried it.

@kevinrr888
Copy link
Member Author

kevinrr888 commented Dec 11, 2023

More requested changes:

  • Table deletion is no longer in finally block
  • Use log.info
  • Main now accepts sleep time

Since we should be taking in a sleep time parameter, not sure how this would be done using mvn.

Let me know if the approach using main is sufficient.

* @formatter:off
* Note: In order to run main,
* 1) Build the project
* 2) Copy the accumulo test jar (in /test/target/) to your accumulo installation's
Copy link
Contributor

@keith-turner keith-turner Dec 11, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we could further minimize changes to the test by requiring copying any needed dependencies like junit. The following may be one way to do this.

mvn dependency:copy-dependencies -DincludeGroupIds="org.junit.jupiter"
cp test/target/dependency/junit-jupiter-* $ACCUMULO_HOME/lib/

If that works, then would not need the wrappers around the junit assert method call, which would minimizes the test changes.

justification = "predictable random is ok for testing")
public static void main(String[] args) {
/**
* @formatter:off
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a javadoc. It doesn't make sense to turn off formatting for javadocs... because the end result is still rendered HTML, not formatted plain text. Instead, use html tags, like <p>, <ul>, etc. If you do it right, the javadoc will be formatted reasonably so that it's readable.

Also, if you want < and > to render properly, like you have near the bottom of this javadoc, you're going to need to express it as &lt; or &gt;.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, I updated the comment

Comment on lines 115 to 117
} catch (Exception e) {
log.error(e.toString());
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No need to catch and log. Just let it get thrown through the main method. The stack trace there will be more useful than the truncated exception that goes to the logger.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, changed so main just throws an error now

Comment on lines 84 to 104
* Note: In order to run main,<br>
* 1) Build the project<br>
* 2) Copy the accumulo test jar (in /test/target/) into your accumulo installation's lib
* directory*<br>
* 3) Copy the JUnit dependencies into your accumulo installation's lib directory:<br>
* $ mvn dependency:copy-dependencies -DincludeGroupIds="org.junit.jupiter"<br>
* $ cp test/target/dependency/junit-jupiter-* $ACCUMULO_HOME/lib/<br>
* <br>
* *Ensure the test jar is in lib before the tablet servers start. Restart tablet servers if
* necessary.<br>
* <br>
* Now, this can be run with<br>
* $ accumulo org.apache.accumulo.test.ScanConsistencyIT [props-file] [tmp-dir] [table]
* [sleep-time]<br>
* <br>
*
* [props-file]: An accumulo client properties file<br>
* [tmp-dir]: tmpDir field for the TestContext object<br>
* [table]: The name of the table to be created<br>
* [sleep-time]: The time to sleep (ms) after submitting the various concurrent tasks<br>
* <br>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know if this works, but I was thinking something more along this:

Suggested change
* Note: In order to run main,<br>
* 1) Build the project<br>
* 2) Copy the accumulo test jar (in /test/target/) into your accumulo installation's lib
* directory*<br>
* 3) Copy the JUnit dependencies into your accumulo installation's lib directory:<br>
* $ mvn dependency:copy-dependencies -DincludeGroupIds="org.junit.jupiter"<br>
* $ cp test/target/dependency/junit-jupiter-* $ACCUMULO_HOME/lib/<br>
* <br>
* *Ensure the test jar is in lib before the tablet servers start. Restart tablet servers if
* necessary.<br>
* <br>
* Now, this can be run with<br>
* $ accumulo org.apache.accumulo.test.ScanConsistencyIT [props-file] [tmp-dir] [table]
* [sleep-time]<br>
* <br>
*
* [props-file]: An accumulo client properties file<br>
* [tmp-dir]: tmpDir field for the TestContext object<br>
* [table]: The name of the table to be created<br>
* [sleep-time]: The time to sleep (ms) after submitting the various concurrent tasks<br>
* <br>
* Note: In order to run main,
* <ol>
* <li>Build the project
* <li>Copy the accumulo test jar (in /test/target/) into your accumulo installation's lib directory
* <li>Copy the JUnit dependencies into your accumulo installation's lib directory:
* <ul>
* <li>mvn dependency:copy-dependencies -DincludeGroupIds="org.junit.jupiter"
* <li>cp test/target/dependency/junit-jupiter-* $ACCUMULO_HOME/lib/
* </ul>
* <li>Ensure the test jar is in lib before the tablet servers start. Restart tablet servers if
* necessary.
* <li>Run with: bin/accumulo org.apache.accumulo.test.ScanConsistencyIT [props-file] [tmp-dir] [table]
* [sleep-time]
* </ol>
*
* [props-file]: An accumulo client properties file<br>
* [tmp-dir]: tmpDir field for the TestContext object<br>
* [table]: The name of the table to be created<br>
* [sleep-time]: The time to sleep (ms) after submitting the various concurrent tasks

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reformatted similarly. From running the QA checks, maven didn't like the unordered list nested within the ordered list which is why I have the third list element the way it is.

@ctubbsii ctubbsii added this to the 3.1.0 milestone Jul 12, 2024
@dlmarion dlmarion changed the base branch from main to 3.1 August 26, 2024 12:04
@ctubbsii ctubbsii changed the base branch from 3.1 to main March 13, 2025 22:42
@ctubbsii ctubbsii modified the milestones: 3.1.0, 4.0.0 Mar 13, 2025
Copy link
Contributor

@dlmarion dlmarion left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have no issue with the code changes by themselves, but I wonder if this is the best place for them. IMO, this functionality will not be remembered when it comes time to perform release testing as I think the majority of testing occurs from the accumulo-testing repo. If this is merged, then I would suggest that the release testing section of the website be updated to reference this test and any other standalone-capable ITs.

@dlmarion
Copy link
Contributor

I did a quick look in the test module, and it looks like the following classes may work in a standalone capacity:

TestIngest
TestMultiTableIngest
VerifyIngest
TestRandomDeletes

These classes aren't tests, but utilities that ITs use.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Refactor scan consistency IT so that it can also be run standalone

6 participants