[
https://issues.apache.org/jira/browse/UIMA-4655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14970907#comment-14970907
]
Lou DeGenaro commented on UIMA-4655:
------------------------------------
In ducc.default.properties is the configuration property:
# The number of "slices" of size "jd.share.quantum" kept in reserve.
# The Orchestrator makes Reservation requests to RM to get Reservations
# (Job Driver hosts) each of which is then subdivided into "slices", one
# per JD. This number specifies the number of unused "slices" that should
# be kept on-hand in anticipation of newly submitted jobs (default 2)
ducc.jd.share.quantum.reserve.count = 3
There are several possibilities to address potential oscillation (churn):
1. have two thresholds, reserve.count.min: always ask for reservation when
crossed, reserve.count.max: don't attempt to give back until crossed
2. have the current single boundary, but don't give back until some expiry
threshold for re-use has be crossed
3. leave as is: OR should always use the least reservations possible
4. other?
> Investigate if JD scheduler releases its extra reservations too frequently
> ---------------------------------------------------------------------------
>
> Key: UIMA-4655
> URL: https://issues.apache.org/jira/browse/UIMA-4655
> Project: UIMA
> Issue Type: Improvement
> Components: DUCC
> Reporter: Burn Lewis
> Priority: Minor
> Fix For: 2.1.0-Ducc
>
>
> A released reservation may be assigned to a job and then a short time later
> removed and handed back to the JD ... could cause churn.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
