[
https://issues.apache.org/jira/browse/DIRSERVER-2192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16017283#comment-16017283
]
Emmanuel Lecharny commented on DIRSERVER-2192:
----------------------------------------------
Be sure that your configuration declares the partitions you are using,
otherwise, you won't see anything. Can you attach your rootDSE as LDIF ?
Otherwise :
1) Database corruption. This is a known JDBM issue that need to be fixed.
Mavibot is supposed to fix it, but it's not yet ready.
2) The repair command process the master table, and recreate all the index
based on your configuration. It may fail if the master table is itself
corrupted...
3) Repair will not damage your database. Worse case scenario, it will not be
able to recreate the indexes, if the master table is itself corrupted
4) Sadly, you will have to wait for mavibot with transaction support :/
A bit of explanation about this database corruption now :
JDBM has transactions support, but limited to a single b-tree. When an update
is done, it's updating the master table, which contains the entries, and all
the indexes. If two update occur at the very same time, it's possible that one
update modify one of the index while the other update was modifying it.
We have tried to add locks in order to limit the potential corruptions, but
it's a complex task.
The only viable solution is to have cross-b-tree transaction support, something
that Mavibot will bring. It's currently being developed - we already have a
working version, but without transaction support - but it takes a lot of time I
currently don't have... (day job, new born baby, etc).
The current situation is that Mavibot has the 'add' operation implemented with
cross-b-tree transaction support (and it's damn fast), I have to finish the
'delete' operation (it's a full week of work, if I can squeeze that in my
agenda). The next step will be to implement the browse operation within a
transaction (wrosing works, but it as to be transactional too) and a free page
management.
I wish I can spend the few needed weeks to get it completed, because,
seriously, this corruption situation is a nightmare.
In the mean time, the only real workaround is doing a regular backup of your
data...
> apcheds M23 - ERR_554 AND ERR_562
> ---------------------------------
>
> Key: DIRSERVER-2192
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2192
> Project: Directory ApacheDS
> Issue Type: Bug
> Reporter: sasha
> Priority: Critical
>
> once a week im getting this errors , the only solution is to restart apacheds
> ,
> how can i fix it?
> Unexpected exception forcing session to close: sending disconnect notice to
> client.
> java.lang.Error: ERR_554 double get for block 11,085
> at jdbm.recman.RecordFile.get(RecordFile.java:185)
> at
> jdbm.recman.PhysicalRowIdManager.allocNew(PhysicalRowIdManager.java:202)
> at
> jdbm.recman.PhysicalRowIdManager.alloc(PhysicalRowIdManager.java:177)
> at
> jdbm.recman.PhysicalRowIdManager.update(PhysicalRowIdManager.java:101)
> at jdbm.recman.BaseRecordManager.update(BaseRecordManager.java:281)
> at
> jdbm.recman.CacheRecordManager.updateCacheEntries(CacheRecordManager.java:417)
> at jdbm.recman.CacheRecordManager.commit(CacheRecordManager.java:349)
> at
> org.apache.directory.server.core.partition.impl.btree.jdbm.JdbmTable.sync(JdbmTable.java:976)
> at
> org.apache.directory.server.core.partition.impl.btree.jdbm.JdbmPartition.sync(JdbmPartition.java:577)
> at
> org.apache.directory.server.core.partition.impl.btree.AbstractBTreePartition.add(AbstractBTreePartition.java:871)
> at
> org.apache.directory.server.core.shared.partition.DefaultPartitionNexus.add(DefaultPartitionNexus.java:361)
> at
> org.apache.directory.server.core.api.interceptor.BaseInterceptor$1.add(BaseInterceptor.java:107)
>
>
>
>
>
>
>
>
>
>
> [03:28:29] WARN
> [org.apache.directory.server.ldap.LdapProtocolHandler] - Unexpected exception
> forcing session to close: sending disconnect notice to client.
> java.lang.Error: ERR_562 Offset too large for record header (11,085:30,012)
> at jdbm.recman.RecordHeader.<init>(RecordHeader.java:83)
> at
> jdbm.recman.PhysicalRowIdManager.allocNew(PhysicalRowIdManager.java:224)
> at
> jdbm.recman.PhysicalRowIdManager.alloc(PhysicalRowIdManager.java:177)
> at
> jdbm.recman.PhysicalRowIdManager.update(PhysicalRowIdManager.java:101)
> at jdbm.recman.BaseRecordManager.update(BaseRecordManager.java:281)
> at
> jdbm.recman.CacheRecordManager.updateCacheEntries(CacheRecordManager.java:417)
> at jdbm.recman.CacheRecordManager.commit(CacheRecordManager.java:349)
> at
> org.apache.directory.server.core.partition.impl.btree.jdbm.JdbmTable.sync(JdbmTable.java:976)
> at
> org.apache.directory.server.core.partition.impl.btree.jdbm.JdbmPartition.sync(JdbmPartition.java:577)
> at
> org.apache.directory.server.core.partition.impl.btree.AbstractBTreePartition.add(AbstractBTreePartition.java:871)
> at
> org.apache.directory.server.core.shared.partition.DefaultPartitionNexus.add(DefaultPartitionNexus.java:361)
> at
> org.apache.directory.server.core.api.interceptor.BaseInterceptor$1.add(BaseInterceptor.java:107)
> at
> org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:341)
> at
> org.apache.directory.server.core.journal.JournalInterceptor.add(JournalInterceptor.java:139)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
