EdColeman opened a new pull request, #2975: URL: https://github.com/apache/accumulo/pull/2975
Issue https://github.com/apache/accumulo/issues/2968 identified an issue with handling FATEs when there are transactions without a `top` and when using ReadOnlyRepo. This is an experiment to see if ReadOnlyRepo can be used instead of reverting code to use ZooStore. Metrics and status commands only need to read FATE status and it would be a coding error if they attempted to update a FATE. It was assumed (I guess incorrectly) that ZooStore when wrapped by a ReadOnlyRepo was functional equivalent for read operations. This replace the requireNonNull check with a DummyRepo when a null Repo is used to create a ReadOnlyRepo. All sunny tests pass, and using and uno instance and a slow iterator - I created and then failed a compaction, killed theAccumulo processes and then restarted. The manager came up without the reported error and the `admin fate --summary` command works. I think this replicates the failing conditions, but not sure. ``` Report Time: 2022-09-27T23:14:06Z Status counts: FAILED: 1 Command counts: TABLE_COMPACT: 1 Step counts: : 1 Fate transactions (oldest first): Status Filters: [NONE] Running txn_id Status Command Step (top) locks held:(table id, name) locks waiting:(table id, name) 0:12:04 6859ad991d4ebd0a FAILED TABLE_COMPACT held:[] waiting:[] ``` This submitted as a draft for review. I am not sure that I replicated the necessary failure cases to trigger the issue or if this approach is desired, but it does seem to point to alternative approaches may be possible. -- 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]
