directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: Problem of JDBM being hard(impossible) to reconfigure once it is initialized
Date Sun, 20 May 2012 22:12:58 GMT
On Wed, May 16, 2012 at 6:58 AM, Göktürk Gezer <> wrote:
> Hi Everyone,
> As i told you in OSGI branch update, JDBM is so immutable in runtime. Almost
> every setter calls checkInitialized() method first which throws an exception
> when its already initialized.

This may be unavoidable but I am not qualified to make this call. At
the present moment I am not familiar enough with the internals to
understand how each setting would impact a reconfiguration. It may be
trivial with some settings like for example cache settings by changing
just a few things in JDBM.

In the worst case, if reinitialization with re-configuration must take
place then the proper management can be handled. For example changing
the files/directory path for the record manager for example can occur
with a move of the actual files after the shutdown before the
re-configuration, and before restarting the record manager service
with the new setting for the the db file. Just giving this as one
example. The other settings might require less management overheads.

> We have to change that behavior in as much aspects of it as we can.
> Otherwise there is no point in going into OSGI. However i can't always be
> sure what my changes might lead on runtime. I need some serious help here,
> especially from those are actively working on JDBM, otherwise i'll jump into
> trial and error cycle which will probably last long.
> Here is the current configuration points for JdbmPartition:

OK Jdbm partition unlike jdbm internals proper I have some suggestions
on. Some settings are not that difficult to deal with on
re-configuration events.

These should be easier to handle:

> cacheSize(int)
> optimizerEnabled(boolean)
> syncOnWrite(boolean)

These below I suspect will impose many more management issues to
properly reconfigure on the fly due to file movements and the creation
of new indices (deletion of old indices).

> indexedAttributes(List<Index>)
> partitionPath(File)
> suffixDn(Dn)
> Currently none of them is reconfigurable, once the partition is initialized.


> However i need to know which are actually reconfigurable among these ones.
> And which are not really reconfigurable and why?
> Every reconfiguration will invoke some setter method at desired
> configuration point. So i guess we can make this reconfigurations work
> actually based on it's initialized or not, rather than throwing an exception
> blindly.

Of course we want re-configuration to be hot because that's really
cool. Sometimes you just don't have the option of shutting down the
server. Then there are software updates to the actual component and
that adds yet another dimension of problems to hot reconfiguration. In
the case of the JDBM partition some changes that change the structure
will make it so the jdbm db files are no longer compatible. So hot
deploys of new versions are not easy or may require long running

Another option or approach can be to handle some of these long running
reconfiguration or software component (bundle) update events not hot
(live) while the server is up and running but after a restart. However
I do not recommend this. There are easy ways to mitigate all these

> For your information, as we have the lifecycle control capability of
> components created from within ApacheDS, we can implement some fancy stuff.
> Like re-instantiating a component when one of its immutable property is
> changed, or stop it and remove from DirectoryService when one of its
> immutable property is changed to prevent accepting operations while
> reconfiguring. These migtht be implemented in case there is " no
> possibility! " to handle reconfigurations in live and initialized
> JdbmPartition reference.

This is the difference between two different modes of reconfiguration:

(1) An "in-place" re-configuration event recovery by a reconfigured
component while it continues to operate.
(2) A component instance swap out where the reconfiguration causes a
new instance of the component to be constructed and configured with
the new settings while on standby. Until the standby is started and
operational the old component continues to operate. Then the old is
shutdown after a swap out.

Overall the #2 approach is much better in my opinion. Why? Because you
can never predict the outcome of in place modifications to settings.
Changing the component directly may not be something the bundle
developer accounted for right?

Of course there's the events that are propagated by the OSGi container
when such an event does occur. I imagine these events have fired and
then the actual getter/setter configuration method is invoked in the
framework. Is this correct to presume?

I think with option #2 we can be more certain that reconfigurations
are better accounted for by bundle developers.

Best Regards,
-- Alex

View raw message