-
Notifications
You must be signed in to change notification settings - Fork 468
replaces Manager with new FateEnv interface in fate code #5944
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
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.
server/manager/src/main/java/org/apache/accumulo/manager/tableOps/FateEnv.java
Outdated
Show resolved
Hide resolved
| @Override | ||
| public void recordCompletion(ExternalCompactionId ecid) { | ||
| getCompactionCoordinator().recordCompletion(ecid); | ||
| } |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
accumulo/server/manager/src/main/java/org/apache/accumulo/manager/Manager.java
Lines 1528 to 1530 in 1168832
| public VolumeManager getVolumeManager() { | |
| return getContext().getVolumeManager(); | |
| } |
| @Override | ||
| public Events getEvents() { | ||
| return nextEvent; | ||
| } |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
renamed in b6905d7
There was a problem hiding this comment.
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
server/manager/src/main/java/org/apache/accumulo/manager/ManagerClientServiceHandler.java
Show resolved
Hide resolved
| import org.apache.accumulo.manager.Manager; | ||
|
|
||
| public abstract class ManagerRepo implements Repo<Manager> { | ||
| public abstract class AbstractRepo implements Repo<FateEnv> { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
renamed in d5a63a8
| 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); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| 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); |
| int skip = | ||
| ctx.getTableConfiguration(bulkInfo.tableId).getCount(Property.TABLE_BULK_SKIP_THRESHOLD); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| 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) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| private Optional<KeyExtent> deleteTabletFiles(ServerContext ctx, FateId fateId) { | |
| private Optional<KeyExtent> deleteTabletFiles(Ample ample, FateId fateId) { |
can pass even less
| Utils.unreserveTable(env.getContext(), tableId, fateId, LockType.WRITE); | ||
| Utils.unreserveNamespace(env.getContext(), namespaceId, fateId, LockType.READ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| 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 {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| 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) {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| 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.
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.