directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Selcuk AYA <>
Subject Re: Questions about the design of the "component-hub"
Date Mon, 28 Nov 2011 18:03:30 GMT
On Mon, Nov 28, 2011 at 6:24 PM, Göktürk Gezer <> wrote:
> On Mon, Nov 28, 2011 at 11:56 AM, Alex Karasulu <>
> wrote:
>> On Mon, Nov 28, 2011 at 2:25 AM, Göktürk Gezer <> wrote:
>> > Hi Devs,
>> > As i go through implementing component-hub, i couldn't think clearly
>> > about
>> > some things, so i need some pointers on them. I've made some decisions
>> > on
>> > code based on my experiments but i need to hear more from you on these
>> > specific issues.
>> > component-hub is responsible for providing main extendibility
>> > facilities,
>> > which contains the DIT configuration hooks. component-hub is providing
>> > the
>> > DIT configuration hooks as a way for users to configure the component
>> > instances.( the instance of a EventInterceptor for example). Then some
>> > DirectoryListener implementation will listen for specified DIT entries
>> > for
>> > changes and then reconfigure the instances. First question is whether
>> > should
>> > i use PersistentSearch or implement DirectoryListener interface myself.
>> > DirectoryListeners are called by EventInterceptor so that will make the
>> > listening code have to go through LdapCoreSession. How PersistentSearch
>> > is
>> > different? Is there any mechanism other than these two??
>> OBJECTIVE: Detect changes to LDAP backed component configurations and
>> react to them.
>> PersistentSearch is a protocol mechanism (over the wire) used to
>> detect changes to entries (in remote LDAP servers) implemented using
>> controls. You issue a search request with the persistent search
>> control and specifying an area of the DIT to watch. The search never
>> completes unless you abort it and it just sends you back entries if
>> they change with a control indicting the nature of the change. It's a
>> hack if you ask me. So this mechanism can work for remote and local
>> servers but you'll go through the wire, the protocol, and will pay a
>> big price for it from the number of threads used to encoding/decoding
>> etc etc.
>> Another way to detect changes but only to a local (in the same process
>> space) DIT, is by using the event listener mechanism provided by the
>> Event subsystem of the DirectoryService. This does essentially the
>> same thing that persistent search does for the same local directory
>> service but better and with less overhead. "Better", in that it allows
>> you to see exactly what attributes changed and how which is a tiny bit
>> more resolution than from the response control you get back with the
>> persistent search mechanism.
>> 1). You're local to the data anyway, configuring local components
>> 2). Less overhead, more efficient faster ... yada yada
>> 3). It's a better programatic interface.
>> 4). Does everything you need it to do.
>> This of course is for the solid state of configuration in DIT
>> operation after the server has already bootstrapped and is online. To
>> actually bootstrap the server you'll probably need to read data kept
>> in LDIF files in the configuration partition folder on disk as if it's
>> stored in an LDAP server or a live partition but there is no LDAP
>> server yet, nor is there a live partition yet.
>> Makes sense?
> Okey then, i just wondered what PersistentSearch is meant to. compenent-hub
> uses event mechanism already. I'm leaving it like that.
>> > Second thing is like chicken-and-egg problem, specifically about
>> > Interceptors. To add the custom generated schemas and the DIT
>> > configuration
>> > hooks for instances, the current code access the server through session
>> > (LdapCoreSessionConnection). But for LdapCoreSession to work as
>> > expected,
>> > the interceptors are needed(at least, to work in the way it meant to).
>> > How i
>> > solved this issue is by deferring all the write operations until
>> > DirectoryService is fully initialized. component-hub will be able to
>> > access,
>> > instantiate and use the interceptors( and other types of components).
>> > However, until its being notified of full initialization of
>> > DirectoryService, it defers the custom schema and DIT configuration hook
>> > entries to be written to DIT. Is there any problem with that approach
>> > that i
>> > couldn't see? This approach is clear but it may introduce some
>> > rendezvous
>> > like concurrency management into code, increasing server startup about 1
>> > second. The other way to do is initializing component-hub with the
>> > DirectoryService reference having its Schema and Config Partition set.
>> > And
>> > then we access the partitions directly without going through nexus and
>> > interceptors. But to handle it with the second way, we must be sure
>> > nothing
>> > is dependent on Interceptors until server is fully initialized.(*1).
>> > Which
>> > way would you choose?
>> I'd implement an LDIF file reading LdapConnection that is just
>> READ-ONLY with just simple operations enabled to read what we need
>> from the configuration at startup. Then you can use this object at
>> initialization/bootstrap time to get at the configuration data you
>> need in the LDIF files stored on disk. Then there is no chicken and
>> egg problem. Then after bootstrapping you just throw away this
>> LdifFileLdapConnection or whatever you want to call it and can use the
>> session connections instead for steady solid state operation after
>> startup.
> I couldn't get my answer on that actually. First of all, the configuration
> information for component-hub and individual components are not all in ldif
> format. All the configurations end up being an entry in DIT but i thought
> saving the configuration like that is not feasible for many reasons. We have
> to do many housekeeping to leave DIT clear, after every OSGI operation if we
> go that way. That's why configuration is kept per component:
> * When we uninstall an individual component from the OSGI framework, all of
> its schema and configuration entries in DIT are cached, leaving DIT as this
> component has never been installed.
> * When we install that component later time, its cache is stored in schema
> and config partitions.
> Schema caches are kept as ldif files, but configuration caches are kept as
> java property files. This is gives component-hub an ability to fetch the
> configuration but configuration alone, and then hook it somewhere in the DIT
> dynamically. This caching system is designed for server runtime in focus,
> but its making server startups-shutdowns bulky.
> But in the time i'm writing this, i realized this system is not resilliant
> for disaster scenarios. I must change it to load configurations from
> server's config partition itself and do some housekeeping to make DIT
> reflect the current status of the OSGI container as much as it can. I like
> it when ideas come to your mind in the middle of writing an email :)
>> > (*1) init() method of SubEntryInterceptor is using nexus to do some
>> > search.
>> > But at that point in the code no partition is added to the nexus, not
>> > even
>> > schema partition is set on DirectoryService. What exactly the code there
>> > is
>> > doing, is it broken or am i missing something?
>> Sorry don't have the code up in your branch. Let me set that up and I
>> can be more useful to you.
> Its on the trunk also.

It seems that such interceptors query the system partition and system
partition is added to nexus by the time inits are done on the

>> --
>> Best Regards,
>> -- Alex
> Regards,
> Gokturk


View raw message