On 11/29/11 11:28 AM, Alex Karasulu wrote:
On Tue, Nov 29, 2011 at 11:59 AM, Emmanuel Lecharny<elecha...@gmail.com> wrote:
On 11/28/11 10:56 AM, Alex Karasulu wrote:
On Mon, Nov 28, 2011 at 2:25 AM, Göktürk Gezer<gokt...@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.
+1. This is definitively the way to go.
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.
The Config is read *before* the DS is started. This is actually the very
first thing we do. You must assume the configuration partition is available,
and it's browsable. You don't need the LDAP server or the DS to access the
information stored there, as we have it managed by an AvlPartition (with its
own searchengine and all what is needed).
Makes sense?
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.
We already have it. This is the way the config in dit is handled.
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.
Keep in mind that since 2.0.0-M1, we use the configuration in DIT, which is
read before we initialize anything, as we need to read the configuration to
be able to "cofigure" the server. This solve the chicken/egg issue.
That solves a great deal of problems. So the configuration partition
is setup and available for reads without having to setup any other
ApacheDS machinery?
From the top of my head, yes. As every little configurable part of ADS
is configured with what has been stored in the DIT, it's totally natural.
Is the raw partition used for access? How is this going to change with
some of the movements done by Selcuk to move search out of the
partition into an upper layer?
We read the LDIF partition from disk, then we load the configuration
elements as POJOs. We use reflection to do that.
Your second point is a good question. But afaiu, it's not because the
search is extracted from the partition code that we can't use it without
any other elements from the DS machinery. Or at least, we should be able
to use it independently.
This may need to be discussed.
PS : can you 'reply list' instead of 'reply all' ? Every time you reply
all, I'm forced to select the list instead of your single name, as you
as the recipient is automatically selected as if you sent me a personal
mail. Thanks !
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
