summaryrefslogtreecommitdiffstats
path: root/src/back-sch.c
diff options
context:
space:
mode:
authorAlexander Bokovoy <abokovoy@redhat.com>2015-12-23 14:57:03 +0200
committerAlexander Bokovoy <abokovoy@redhat.com>2015-12-23 14:57:03 +0200
commit38fc0024c2669006a4d71a722a75cf2aeeb3e4bf (patch)
tree73a2febd64b2647e212355f9aa2b0e26aaa61f24 /src/back-sch.c
parentda26d9595e6449009575e8d2a4c888176829a97f (diff)
downloadslapi-nis-38fc0024c2669006a4d71a722a75cf2aeeb3e4bf.tar.gz
slapi-nis-38fc0024c2669006a4d71a722a75cf2aeeb3e4bf.tar.xz
slapi-nis-38fc0024c2669006a4d71a722a75cf2aeeb3e4bf.zip
slapi-nis: populate data trees asynchronously after LDAP server startup
Currently slapi-nis design assumes the map cache is populated by scanning the original trees on plugin start up. This has few consequences: - LDAP server cannot serve LDAP clients until all plugins are initialized - slapi-nis cannot ask SSSD to resolve external identities at this point as SSSD will need to talk to the LDAP server which is at this point not listening for connections. SSSD will put whole IPA domain into offline and always will respond with negative result To solve these issues, schedule tree scan after LDAP server startup. The problem here is that it is not possible to reliably detect when 389-ds starts to listen to the incoming connections. However, it is possible to schedule an event into 389-ds event queue that will run shortly after start of the event loop. Given that the call back function which is registered to be called is called within the event loop thread, one can fire off another thread and wait in the thread function some time until the LDAP server is ready for connections. The time interval is something that would depend on a specific deployment profile but experiments show that having 5 seconds delay should be enough as event queue is created just before starting the listeners.
Diffstat (limited to 'src/back-sch.c')
0 files changed, 0 insertions, 0 deletions