Hi Simon,

Sorry for getting to you late.  Looks like Emmanuel got to you first but let me attempt to answer
some of your questions as well.

On 9/26/07, Simon.Temple@saaconsultants.com <Simon.Temple@saaconsultants.com> wrote:



When we implemented early releases of DS 1.0 we found that under certain conditions (e.g. uncontrolled shutdown) the jdbm store/indexes became damaged.

Is this still the case with DS 1.5.x ?  Have you tried to reproduce?

To enable our customer service department to determine if this was the cause of a reported fault, I added a method to our directory MBean to enumerate all of the jdbm indexes/entries.  If it failed then we have a procedure to remove all the jdbm store folders and restart DS with a backup LDIF.

Ahhh I see.  I think you may be at some point interested in the change log service we've recently started talking about
which would automatically produce this LDIF.

Whereas this capability is not a runtime requirement of our systems it is an important operational tool as jdbm storage has proved to be a little 'fragile'.

Oh we'd sure appreciate feedback on the problems you've found so we can make this a bit better.

So to reword my question:  How can I run an integrity check on the underlying jdbm stores?

I'd have to have an idea of the kind of broken state you're exactly referring to.  Perhaps if you have such a
busted partition I could look at the actual state it is left in to understand the class of problem.

Really without having some reference point of the information you expect in the backing store it's pretty hard.  I
need more information.