ddanielr commented on code in PR #4223:
URL: https://github.com/apache/accumulo/pull/4223#discussion_r1478848471
##########
server/compactor/src/main/java/org/apache/accumulo/compactor/Compactor.java:
##########
@@ -449,9 +449,11 @@ protected void
updateCompactionCompleted(TExternalCompactionJob job, TCompaction
protected TExternalCompactionJob getNextJob(Supplier<UUID> uuid) throws
RetriesExceededException {
final long startingWaitTime =
getConfiguration().getTimeInMillis(Property.COMPACTOR_MIN_JOB_WAIT_TIME);
+ final long maxWaitTime =
+
getConfiguration().getTimeInMillis(Property.COMPACTOR_MAX_JOB_WAIT_TIME);
RetryableThriftCall<TExternalCompactionJob> nextJobThriftCall =
- new RetryableThriftCall<>(startingWaitTime,
RetryableThriftCall.MAX_WAIT_TIME, 0, () -> {
+ new RetryableThriftCall<>(startingWaitTime, maxWaitTime, 0, () -> {
Review Comment:
> What is the relationship between the amount of time that we are willing to
wait for a compaction vs a thrift call?
In this case, we are just modifying the thrift call for getting a compaction
job. This ensures that thrift will backoff at the same rate as the compactor
would if no work was available to it.
>It seems that the thrift call time is going to be related to system size
and system activity. So, if compact max wait was set to 15 min, would we still
want to wait that same amount of time for a thrift call?
Yes, the goal of `MAX_JOB_WAIT` is to set the retry interval for work
requests.
There are two situations where a work request interval is used:
1. Coordinator returns empty job, so compactor thread then sleeps up to the
`MAX_JOB_WAIT` interval.
2. Coordinator is down or unreachable so thrift retries up to the
`MAX_JOB_WAIT` interval.
--
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]
