keith-turner opened a new issue, #6017:
URL: https://github.com/apache/accumulo/issues/6017
**Is your feature request related to a problem? Please describe.**
When the fate operation driving a user initiated compaction or bulk import
is stuck it can be difficult to gather information on the reason its stuck.
Currently the best way to do this may be to enable trace logging in specific
classes and hope that shows something.
**Describe the solution you'd like**
A new fate admin command that provides detailed information about that a
fate operation is currently doing. For example if `123456789` is the fate id of
a user compaction then it could run the following.
```
accumulo admin fate --status 123456789
Compacted 7 of 10 tablets. Compaction id is 400
waiting on tablet 1;e with location 192.168.1.40:9996
waiting on tablet 1;h with location 192.168.1.30:9996
waiting on tablet 1;x with no location
```
Hopefully this could be done by adding a method like the following to Repo
```java
public interface Repo
default void printStatus(ServerContext context, PrintStream out){
out.println("Status not implemented for "+this.getClass().getName());
}
}
```
Then the admin status command could take the top operation off the stack for
the fate operation and call the status command.
Can do this in 2.1 as long as adding the default method to the interface
does not cause problems for deserialization.
**Describe alternatives you've considered**
Stick with the trace logging approach. The user has to enable trace logging
and then wait for the operation to attempt to run again. This approach has
the advantage of giving immediate and targeted information.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
