First, for context, the rubric describing how the DN Pool holding cell feature works is as follows:
There is a table in the APM database called dn_pool_hold_cell whose purpose is to essentially reserve DNs in an effort to prevent concurrent provisioners from simultaneously selecting and provisioning the same DN.
A DN is entered into the dn_pool_hold_cell only when it is selected from the list of available DNs on the provisioning page.
If a DN is in the dn_pool_hold_cell, it will not be available for provisioning, regardless of its state/status in CUCM.
There is a separate, independent process (for simplicity's sake, we'll call it HOLD_CELL_CHECK) which runs every 11 minutes after its first run which checks to see if there are any DNs in the dn_pool_hold_cell table.
There is no way to change the frequency at which the HOLD_CELL_CHECK process runs, as it is an integrated, database-level process which neither the customer nor Support is able to modify on the fly.
If the dn_pool_hold_cell table is empty, no action is taken.
If the dn_pool_hold_cell table is not empty, HOLD_CELL_CHECK will only remove any DNs that were entered longer than 11 minutes ago.
Because of this, a DN could remain in the dn_pool_hold_cell anywhere from 11min, 1sec (minimum) to 21min, 59sec (maximum).
The customer is requesting a feature enhancement to allow the frequency at which the HOLD_CELL_CHECK process runs (and, subsequently, the amount of time a DN could spend in the dn_pool_hold_cell) to be a customer-configurable value. The default time of 11 minutes would remain as the default, but could be lowered or raised (within an acceptable range determined by the developers) to better suit the customer's use case.
This customer in particular would prefer that the HOLD_CELL_CHECK process ran every 5 minutes (instead of every 11 minutes) which would, theoretically, result in a DN being in the dn_pool_hold_cell for a minimum of 5min, 1sec and a maximum of 9min, 59sec.
Note: When I discussed this with the development team, the product owner considered the addition of a customer-accessible way to remove DNs from the hold cell manually via the APM web GUI. While this could be a reasonable solution for one-off DN removals, it would not be efficient for customers who frequently experience long DN release times.
Will Powers
