1. OMG Issue

DEPL4 — Target Manager Resource Commitment Granularity

  • Key: DEPL4-22
  • Legacy Issue Number: 7880
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    At the moment, resources are committed and later released according to
    a Deployment Plan – the Execution Manager just sends over the full
    plan, and the Target Manager has to pick it apart. We considered this
    a good idea – after all, the plan contains all information about
    resources that will be used by an application. In retrospect, however,
    it looks like a design break. The plan contains a lot of information
    that the Target Manager is not interested in. So the Target Manager
    has to dissect information that it should not need to see in the first

    Also, and maybe more importantly, the only way of releasing resources
    is by sending the very same plan to the Target Manager all over again,
    as the Target Manager does not keep track of allocations.

    This does not allow for the early release of resources, in case the
    application does not need all that were reserved, or in case part of
    the application finishes early.

    Therefore I propose to replace the current "commitResources" and
    "releaseResources" operations with a per-application "resource
    commitment" object that allows to commit and release resources in a
    fine-grained manner, and that keeps track of the current commitment,
    so that the remaining resources that are in use by an application
    can be released by simply destroying the object.

    By not sending the full Deployment Plan, that would also dramatically
    cut communication between the Execution Manager and the Target Manager.

  • Reported: DEPL 1.0 — Mon, 25 Oct 2004 04:00 GMT
  • Disposition: Resolved — DEPL 4.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT