directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Göktürk Gezer <gokturk.ge...@gmail.com>
Subject Re: Questions about the design of the "component-hub"
Date Mon, 28 Nov 2011 19:32:18 GMT
On Mon, Nov 28, 2011 at 8:03 PM, Selcuk AYA <ayaselcuk@gmail.com> wrote:

> On Mon, Nov 28, 2011 at 6:24 PM, Göktürk Gezer <gokturk@apache.org> wrote:
> >
> >
> > On Mon, Nov 28, 2011 at 11:56 AM, Alex Karasulu <akarasulu@apache.org>
> > wrote:
> >>
> >> On Mon, Nov 28, 2011 at 2:25 AM, Göktürk Gezer <gokturk@apache.org>
> 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.
> >>
> >> SO YOU SHOULD MOST LIKELY USE THE EVENT MECHANISM. This because:
> >>
> >> 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
> interceptors.
>

Yeah i'm confused about addInterceptor() and setInterceptors() methods on
DirectoryService. I see now its ok.


>
> >>
> >> --
> >> Best Regards,
> >> -- Alex
> >
> > Regards,
> > Gokturk
>
> regards,
> Selcuk
>

Mime
View raw message