Skip to content

Conversation

@keith-turner
Copy link
Contributor

Added a FateEnv interface that replaces direct usage of the Manager type in fate operations. This refactoring could support changes to run fate operations outside of the Manager process.

Added a FateEnv interface that replaces direct usage of the Manager type
in fate operations. This refactoring could support changes to run fate
operations outside of the Manager process.
@keith-turner keith-turner added this to the 4.0.0 milestone Sep 30, 2025
Comment on lines 567 to 570
@Override
public void recordCompletion(ExternalCompactionId ecid) {
getCompactionCoordinator().recordCompletion(ecid);
}
Copy link
Member

Choose a reason for hiding this comment

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

This method breaks the pattern in FateEnv. Most of the other methods get a management utility, like the VolumeManager, the Splitter, the ServiceLock, etc. To follow the pattern, I'd imagine FateEnv would return a getCompactionCoordinator, instead of recording a completion directly.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I was thinking ahead here to running fate outside of the manager, in that situation accessing the entire compaction coordinator would not be possible. Would need to be some subset of it and this was all fate needed so I just made that single method available for now.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

VolumeManager, the Splitter, the ServiceLock

Those things would likely be easily available in another process. One thing I noticed is the manager has a few methods for things that it just gets from the server context. Wanted to inline those, but there were already so many changes.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is an example of a method I wanted to inline

public VolumeManager getVolumeManager() {
return getContext().getVolumeManager();
}

Comment on lines 1528 to 1531
@Override
public Events getEvents() {
return nextEvent;
}
Copy link
Member

Choose a reason for hiding this comment

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

This reads like it returns a list of events, but it doesn't. Maybe this should return an EventManager?

Copy link
Contributor Author

@keith-turner keith-turner Sep 30, 2025

Choose a reason for hiding this comment

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

Maybe I will rename it to EventPublisher. There is code in the manager for publishing and subscribing to events that is all in memory, the fate code only publishes events so I wanted to only offer that functionality to fate. Thinking ahead that could be RPCs to the manager if fate is running outside the manager.

Copy link
Member

Choose a reason for hiding this comment

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

EventPublisher is a good name

Copy link
Contributor Author

Choose a reason for hiding this comment

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

renamed in b6905d7

Copy link
Contributor Author

Choose a reason for hiding this comment

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

renamed the getter in d38f060

import org.apache.accumulo.manager.Manager;

public abstract class ManagerRepo implements Repo<Manager> {
public abstract class AbstractRepo implements Repo<FateEnv> {
Copy link
Member

Choose a reason for hiding this comment

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

I think this could be further simplified, because by making Repo use a more generic type, FateEnv, it isn't really necessary to have Repo accept a generic parameter... it can just always be FateEnv.

Also, the name "Repo" has always been a bit of a confusing name. Since you're renaming, you could take the opportunity to rename this to something more like "AbstractFateOperation" or "AbstractFateOp", since all the subclasses of this are typically referred to as "fate ops" (hence package names like "tableOps").

Also, this is still in the tableOps package, but it is being used by tserverOps, coordinator ops, etc. It probably needs a new home.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think this could be further simplified, because by making Repo use a more generic type, FateEnv, it isn't really necessary to have Repo accept a generic parameter... it can just always be FateEnv.

Not currently, fate test do use other type parameters in order to make testing simpler. That would be a big change best for another PR, if its even feasible.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

renamed in d5a63a8

Comment on lines +228 to +231
int maxTablets =
ctx.getTableConfiguration(bulkInfo.tableId).getCount(Property.TABLE_BULK_MAX_TABLETS);
int maxFilesPerTablet =
ctx.getTableConfiguration(bulkInfo.tableId).getCount(Property.TABLE_BULK_MAX_TABLET_FILES);
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
int maxTablets =
ctx.getTableConfiguration(bulkInfo.tableId).getCount(Property.TABLE_BULK_MAX_TABLETS);
int maxFilesPerTablet =
ctx.getTableConfiguration(bulkInfo.tableId).getCount(Property.TABLE_BULK_MAX_TABLET_FILES);
var tableConfig = ctx.getTableConfiguration(bulkInfo.tableId);
int maxTablets =
tableConfig.getCount(Property.TABLE_BULK_MAX_TABLETS);
int maxFilesPerTablet =
tableConfig.getCount(Property.TABLE_BULK_MAX_TABLET_FILES);

Comment on lines +255 to +256
int skip =
ctx.getTableConfiguration(bulkInfo.tableId).getCount(Property.TABLE_BULK_SKIP_THRESHOLD);
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
int skip =
ctx.getTableConfiguration(bulkInfo.tableId).getCount(Property.TABLE_BULK_SKIP_THRESHOLD);
int skip =
tableConfig.getCount(Property.TABLE_BULK_SKIP_THRESHOLD);

if this is in scope of my other suggestion

}

private Optional<KeyExtent> deleteTabletFiles(Manager manager, FateId fateId) {
private Optional<KeyExtent> deleteTabletFiles(ServerContext ctx, FateId fateId) {
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
private Optional<KeyExtent> deleteTabletFiles(ServerContext ctx, FateId fateId) {
private Optional<KeyExtent> deleteTabletFiles(Ample ample, FateId fateId) {

can pass even less

Comment on lines +72 to +73
Utils.unreserveTable(env.getContext(), tableId, fateId, LockType.WRITE);
Utils.unreserveNamespace(env.getContext(), namespaceId, fateId, LockType.READ);
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
Utils.unreserveTable(env.getContext(), tableId, fateId, LockType.WRITE);
Utils.unreserveNamespace(env.getContext(), namespaceId, fateId, LockType.READ);
Utils.unreserveTable(context, tableId, fateId, LockType.WRITE);
Utils.unreserveNamespace(context, namespaceId, fateId, LockType.READ);


@Override
public void undo(FateId fateId, Manager manager) throws Exception {}
public void undo(FateId fateId, FateEnv manager) throws Exception {}
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
public void undo(FateId fateId, FateEnv manager) throws Exception {}
public void undo(FateId fateId, FateEnv env) throws Exception {}


@Override
public void undo(FateId fateId, Manager m) {}
public void undo(FateId fateId, FateEnv m) {}
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
public void undo(FateId fateId, FateEnv m) {}
public void undo(FateId fateId, FateEnv env) {}

Could grep for FateEnv m to see if there are other occurrences of something similar

Not for this PR but, could also just delete this method (and others that don't do anything for undo) since default impl does nothing already. Alternatively, might be better to make undo (maybe isReady too) in AbstractFateOperation abstract methods so implementers have to actively consider what isReady and undo should actually do.

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.

3 participants