Closed pki-bot closed 3 years ago
Comment from ftweedal (@frasertweedale) at 2015-11-30 03:25:07
suggested fix:
change search performed by profileChangeMonitor thread (which
is a persistent search also used to load initial profiles)
to SCOPE_SUB
from ou=certificateProfiles,...
requesting
operational attribute numSubordinates
.
The initial search results should be atomic so once numSubordinates
profiles have been processed, the initialisation is complete. Flag
this on the ProfileSubsystem
.
In ProfileSubsystem.init()
, wait (block) for the flag that indicates that
the initial load is complete, before returning.
Comment from ftweedal (@frasertweedale) at 2015-11-30 04:00:23
java.util.concurrent.CountDownLatch
will be useful here.
Comment from mharmsen (@mharmsen) at 2015-12-01 00:26:35
Per CS/DS meeting of 11/30/2015: 10.3 major
Comment from ftweedal (@frasertweedale) at 2015-12-02 02:51:36
attachment pki-frasertweedale-0062-Block-startup-until-initial-profile-load-completed.patch
Comment from mharmsen (@mharmsen) at 2015-12-08 02:34:13
NOTE: Per conversations in IRC, this ticket is slated to be fixed
as patches to Dogtag 10.2.6 on Fedora 22, 23, (and 24 until
such time as it is upgraded to 10.3). The fixes will be
checked into the master branch where they will also be picked
up by Dogtag 10.3 and later releases.
Comment from mharmsen (@mharmsen) at 2015-12-08 02:34:57
Per IRC discussion: Moving from 10.3 --> 10.2.X milestone.
Comment from mharmsen (@mharmsen) at 2016-01-07 04:09:13
Per discussions in the Dogtag 10.3 Triage meeting of 01/06/2016: priority medium
Comment from ftweedal (@frasertweedale) at 2016-01-21 04:07:42
master:
5fae5826e5442d7266681d19f282dc7728062b89 Block startup until initial profile load completed
DOGTAG_10_2_BRANCH:
e8a1d9cbbefb2988092e96b13d0b13254c92d1b2 Block startup until initial profile load completed
Comment from mharmsen (@mharmsen) at 2016-01-21 23:40:48
DOGTAG_10_2_6_BRANCH:
b16968402bb414042b3a529097ca934f165d62b9 Block startup until initial profile load completed
Comment from ftweedal (@frasertweedale) at 2017-02-27 14:00:39
Metadata Update from @frasertweedale:
This issue was migrated from Pagure Issue #1702. Originally filed by ftweedal (@frasertweedale) on 2015-11-23 00:56:58:
The CMS status is reported as 'running' before the initial loading of profiles (which for the LDAPProfileSubsystem happens asynchronously) is complete, potentially causing failures where clients issue requests to profiles that are not yet loaded.
Suggested fix is to perform initial loading of profiles synchronously or ensure CMS status does not report 'running' until the LDAPProfileSubsystem is ready.