Skip to content

Globally Unique FATE Transaction Ids - Part 1#4191

Merged
keith-turner merged 10 commits into
apache:elasticityfrom
kevinrr888:elasticity-feature-4044
Feb 1, 2024
Merged

Globally Unique FATE Transaction Ids - Part 1#4191
keith-turner merged 10 commits into
apache:elasticityfrom
kevinrr888:elasticity-feature-4044

Conversation

@kevinrr888
Copy link
Copy Markdown
Member

@kevinrr888 kevinrr888 commented Jan 24, 2024

PR for #4044. The end goal is to have the stronger type FateId replace the current representation of a transaction id (which is just a long). This was brought about from the addition of the AccumuloStore class - there are now two fate instance types associated with a transaction - META (for ZooStore) or USER (for AccumuloStore). FateId is a new class which includes the FateInstanceType and the transaction id.

TODO:

  • Create new class FateId to replace FateTxId
  • Change the stores to use FateId. Start with ReadOnlyFateStores. Resolve issues stemming from these changes.
  • Change Fate to use FateId. Resolve issues stemming from these changes.
  • Change Repo to use FateId. Resolve issues stemming from these changes.
  • AdminUtil and Admin need to use FateId. Deferred for now. Need #4168 completed first.
  • Delete FateTxId when all uses have been replaced with FateId

This PR is ready for review and potentially to be merged. Will need at least another PR for the rest of the changes.

A WIP for apache#4044. The end goal is to have the stronger type FateId replace the current representation of a transaction id (which is just a long). This was brought about from the addition of the AccumuloStore class - there are now two fate instance types associated with a transaction - META (for ZooStore) or USER (for AccumuloStore). FateId is a new class which includes the FateInstanceType and the transaction id.
Current changes:
- FateTxId replaced with new class FateId
- Started with changes in ReadOnlyFateStore and resolved the issues in other classes extending from changing this class.
Still left TODO:
- There are still related problems from the classes I have changed: I have not yet finished going down the entire chain of issues
- Need to change Fate and the associated issues with changing this class
- Need to change Repo and the associated issues with changing this class
- More changes TBD
@keith-turner
Copy link
Copy Markdown
Contributor

In ReadOnlyFateStore will need to change the following to

void runnable(AtomicBoolean keepWaiting, LongConsumer idConsumer);
void runnable(AtomicBoolean keepWaiting, Consumer<FateId> idConsumer);

Copy link
Copy Markdown
Contributor

@keith-turner keith-turner left a comment

Choose a reason for hiding this comment

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

These changes look good so far. Based on what you have done so far do you think it would be possible to break this work in multiple PRs?

return scanner.stream().onClose(scanner::close).map(e -> {
return new FateIdStatus(parseTid(e.getKey().getRow().toString())) {
FateId fateId =
FateId.from("FATE:" + fateInstanceType + ":" + e.getKey().getRow().toString());
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Could have a FateId.from(FateInstanceType it, String hexId) method and do the following

Suggested change
FateId.from("FATE:" + fateInstanceType + ":" + e.getKey().getRow().toString());
FateId.from(fateInstanceType, e.getKey().getRow().toString());

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Yes, good suggestion

@kevinrr888
Copy link
Copy Markdown
Member Author

In ReadOnlyFateStore will need to change the following to

void runnable(AtomicBoolean keepWaiting, LongConsumer idConsumer);
void runnable(AtomicBoolean keepWaiting, Consumer<FateId> idConsumer);

Ah okay. Yeah wasn't too sure exactly how I should go about changing this method. Will make suggested change.

@kevinrr888
Copy link
Copy Markdown
Member Author

These changes look good so far. Based on what you have done so far do you think it would be possible to break this work in multiple PRs?

Yes, this is my thinking of how it could be broken up:

  1. A PR changing ReadOnlyFateStore.java and the issues stemming from this (current PR)
  2. A PR resolving all the issues from deleting FateTxId.java (maybe combined with first)
  3. A PR changing Fate.java and the issues stemming from this
  4. A PR changing Repo.java and the issues stemming from this
  5. Potentially more PRs

However, I'm not sure if this is the best way or if these PRs standalone would actually pass all the git checks/not break the project. Not sure how interlinked everything is.

@kevinrr888 kevinrr888 changed the title Globally Unique FATE Transaction Ids WIP Globally Unique FATE Transaction Ids Jan 25, 2024
Will be deleted later on when it can be safely deleted (after all uses
of FateTxId have been replaced by FateId)
* @return a new FateId object
*/
public static FateId from(FateInstanceType type, String hexTid) {
Pattern hexPattern = Pattern.compile("^[0-9a-fA-F]+$");
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

This can be moved to a static private field so that we can cache the compiled pattern and avoid the expense of creating it each time. Java patterns are thread

- New fromThrift() method in FateId.
- Fate now uses FateId and resolved issues stemming from these changes.
- AdminUtil and Admin do not have FateId fully incorporated yet. Deferred for now. Marked "TODO DEFERRED - ISSUE 4044" in code. Need issue apache#4168 completed first.
- Resolved all compile errors.
@kevinrr888
Copy link
Copy Markdown
Member Author

kevinrr888 commented Jan 30, 2024

Update:

  • New fromThrift() method in FateId.
  • Fate now uses FateId and resolved issues stemming from these changes.
  • AdminUtil and Admin do not have FateId fully incorporated yet. Deferred for now. Marked "TODO DEFERRED - ISSUE 4044" in code. Need #4168 completed first.
  • Resolved all compile errors.
  • Now that it compiles, I am able to run tests but have found that several hang indefinitely. Need to resolve this. (edit: Resolved)
  • Updated the main PR comment to better break down overall goal into smaller sub goals.

Copy link
Copy Markdown
Contributor

@keith-turner keith-turner left a comment

Choose a reason for hiding this comment

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

These changes look good

String txName = (String) txStore.getTransactionInfo(Fate.TxInfo.TX_NAME);

List<String> hlocks = heldLocks.remove(tid);
// TODO DEFERRED - ISSUE 4044
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

We have been using a more specific TODO in the elasticity branch, could use it here

Suggested change
// TODO DEFERRED - ISSUE 4044
// ELASTICITY_TODO DEFERRED - ISSUE 4044

private void transitionToFailed(FateTxStore<T> txStore, Exception e) {
String tidStr = FateTxId.formatTid(txStore.getID());
final String msg = "Failed to execute Repo " + tidStr;
FateId fateId = txStore.getID();
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Could inline this, it was only there to avoid duplicating the FateTxId.formatTid(...) code.

- Inline statement in Fate
- Changed comment about deferral in AdminUtil
@kevinrr888 kevinrr888 marked this pull request as ready for review January 31, 2024 17:08
@kevinrr888 kevinrr888 changed the title WIP Globally Unique FATE Transaction Ids Globally Unique FATE Transaction Ids - Part 1 Jan 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: ✅ Done

Development

Successfully merging this pull request may close these issues.

4 participants