Remove warnings from unused code#6354
Conversation
ctubbsii
commented
Apr 30, 2026
ctubbsii
commented
- Remove unused variables, methods, and parameters, causing IDE compiler warnings
- Also remove warning from unclosed FateStore by placing the new store in a try-with-resources block
- Also removed one false positive potentially unclosed resource warning in LocatorIT by using the ServerContext for altering the system state for the test instead of using the AccumuloClient as a ClientContext
* Remove unused variables, methods, and parameters, causing IDE compiler warnings * Also remove warning from unclosed FateStore by placing the new store in a try-with-resources block * Also removed one false positive potentially unclosed resource warning in LocatorIT by using the ServerContext for altering the system state for the test instead of using the AccumuloClient as a ClientContext
| private static Optional<TServerInstance> deserializeTserverId(FateKeyType type, | ||
| DataInputBuffer buffer) throws IOException { | ||
| return switch (type) { | ||
| case SPLIT, MERGE, COMPACTION_COMMIT -> Optional.empty(); | ||
| case TSERVER_SHUTDOWN -> Optional.of(new TServerInstance(buffer.readUTF())); | ||
| }; | ||
| } | ||
|
|
There was a problem hiding this comment.
@keith-turner I think the tServerInstance field became unused after recent distributed Fate changes, but there remains a FateKey constructor that accepts a TServerInstance that is serialized, but then it is never deserialized. I think there's probably some unnecessary stuff going on here, even after my changes, because it doesn't seem useful to have a code path that serializes a TServerInstance when it will never be used.
There was a problem hiding this comment.
That code was added in #6224. That code is used to ensure there is only a single fate operations to shutdown a specific tserver running at time. I was just following the pattern of the other code when adding that new fate key type. However it usage differs, we never need to read it. For compaction fate keys those need to be read for dead compaction detection. So since we never read it, it did not need to follow the pattern of the other types. Seems ok to remove it and the parts left behind are still in use.
This code uses the fate key to ensure only one operation is initiated per a tserver. The serialized data is used for the FateKey hashcode and equals functions, so that seems like it will still work for comparing them to dedupe.
There was a problem hiding this comment.
In persistent storage the serialized from of the key is used to dedupe by putting it in the Accumulo key for the fate table.
2 participants
