Le 5/23/12 12:01 AM, Selcuk AYA a écrit :
I do not know the OSGI jargon but I believe, at the end, changing
these should reduce to something like this:
1) quiesce the necessary ldap operations: The simplest thing to do
would be to block all operations quiesce all the outstanding
operations. In some cases, it would be enough to block only searches.
There might be some cases where you do not need any blocking at all. I
do not
I'm not comfortable with the idea of quiscing the ldap operations. The
server is supposed to work 24x7, and if we do add some way to modify the
backend config on the fly, then the user should not notice that.
See my comments below.
2) do the configuration: In the end I am assuming the configuration is
delegated to the component itself to do the reconfig.
3) unblock the operations.
For index add:
* queisce any ldap operation that might modify the data. Then notify
the partition to add the index. Partition will scan the master table
and build the index and swap its indexed attributes. Then unlock the
operations.
Adding an index should be done while the server is still able to process
requests. The thing is that the newly added server should not be
available until it has been created. The real problem is that we won't
be able to parse the master table fast enough to have all the
subscequent modifications into it, so this is a two steps operation :
- do a full scan search on the master table, and create the additional
index. We should be safe here, because we will use the current version
of the master table when we start the search.
- then for every modification done after the beginning of step 1, apply
those changes to the index. If we have some more changes since we
started this step, then do it again.
Now, we can use this index.
For index delete:
* block all operations, and remove the index from the indexes list.
Maybe commit this change in partition config. unlock changes. Then
continue deleting index file.
Here, it's simpler. The operation using this index will continue to use
it, until they are done. New operations won't be allowed to use it. Once
the number of requests using this index is 0, then the index can be
deleted. I don't think we need to block any operation here.
For suffixdn change:
* I believe this is a rename operation. again block all operations and
do the rename. Then unblock.
changing teh suffix DN is just a matter of modifying the configuration,
and the DnNode structure. The problem is that we rebuild all the
entries' DN using the partition suffixDn, so we have to be careful when
doing so. The request being processed when the rename occurs should be
fulfilled with the initial suffixDn.
Working directory change;
* Block all opreations and let the parition change its config dir. For
jdbm, this would be a copy of it working directory.
Here, this is an administrative task. Not sure we want to do that on a
running server...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
