[
https://issues.apache.org/jira/browse/DIRSERVER-2047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14339842#comment-14339842
]
Emmanuel Lecharny edited comment on DIRSERVER-2047 at 2/28/15 12:58 PM:
------------------------------------------------------------------------
Ah !
This is a good catch, although the code is correct. The idea is that a page is
split, and we get the new key that has to be moved to the parent from the right
page. Let me explain how it works :
Before the split, the page is full, and we have to inject a new value in it :
{code}
+---+---+---+
| A | B | C |
+---+---+---+
| | |
...<---+ | +--->...
V
+---+---+---+---+
| 1 | 3 | 5 | 7 |
+---+---+---+---+
{code}
Here, the leftmost key of the page is stored in the parent page, thus {{1}} is
also stored in the parent page.
Now, we have to inject the value {{6}}. The underlying page will be split in
two pages :
{code}
+---+---+ +---+---+---+
| 1 | 3 | | 5 | 6 | 7 |
+---+---+ +---+---+---+
{code}
and we have to add a new key ({{6}} here) in the parent page. The result
will be :
{code}
+---+---+---+---+
| A | 1 | 5 | C |
+---+---+---+---+
| | | |
| | | +--->...
| | |
...<---+ | +-------+
V V
+---+---+ +---+---+---+
| 1 | 3 | | 5 | 6 | 7 |
+---+---+ +---+---+---+
{code}
Here, we took the leftmost key of the right page, as it's done in the code :
{code}
K pivot = rightLeaf.keys[0].getKey();
{code}
Now, why do we do :
{code}
if ( pivot == null )
{
pivot = rightLeaf.keys[0].getKey();
}
{code}
when the pivot obviously won't be null ? (and we take the exact same value !)
This is typically a debug piece of code that remained in the code. The (debug)
idea was to put a conditional breakpoint when pivot was null, and redo the same
action, but allowing us to know what was going on. This piece of code has been
added here :
http://svn.apache.org/viewvc/directory/mavibot/trunk/mavibot/src/main/java/org/apache/directory/mavibot/btree/PersistedLeaf.java?r1=1536070&r2=1538151&diff_format=h
I'll remove this useless piece of code, thanks for point it out !
was (Author: elecharny):
Ah !
This is a good catch, although the code is correct. The idea is that a page is
split, and we get the new key that has to be moved to the parent from the right
page. Let me explain how it works :
Before the split, the page is full, and we have to inject a new value in it :
{code}
+---+---+---+
| A | B | C |
+---+---+---+
| | |
...<---+ | +--->...
V
+---+---+---+---+
| 1 | 3 | 5 | 7 |
+---+---+---+---+
{code}
Here, the leftmost key of the page is stored in the parent page, thus {{1}} is
also stored in the parent page.
Now, we have to inject the value {{6}}. The underlying page will be split in
two pages :
{code}
+---+---+ +---+---+---+
| 1 | 3 | | 6 | 5 | 7 |
+---+---+ +---+---+---+
{code}
and we have to add a new key ({{6}} here) in the parent page. The result
will be :
{code}
+---+---+---+---+
| A | 1 | 6 | C |
+---+---+---+---+
| | | |
| | | +--->...
| | |
...<---+ | +-------+
V V
+---+---+ +---+---+---+
| 1 | 3 | | 6 | 5 | 7 |
+---+---+ +---+---+---+
{code}
Here, we took the leftmost key of the right page, as it's done in the code :
{code}
K pivot = rightLeaf.keys[0].getKey();
{code}
Now, why do we do :
{code}
if ( pivot == null )
{
pivot = rightLeaf.keys[0].getKey();
}
{code}
when the pivot obviously won't be null ? (and we take the exact same value !)
This is typically a debug piece of code that remained in the code. The (debug)
idea was to put a conditional breakpoint when pivot was null, and redo the same
action, but allowing us to know what was going on. This piece of code has been
added here :
http://svn.apache.org/viewvc/directory/mavibot/trunk/mavibot/src/main/java/org/apache/directory/mavibot/btree/PersistedLeaf.java?r1=1536070&r2=1538151&diff_format=h
I'll remove this useless piece of code, thanks for point it out !
> Some data can be lost when using ldapadd command to insert data into apacheds
> -----------------------------------------------------------------------------
>
> Key: DIRSERVER-2047
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2047
> Project: Directory ApacheDS
> Issue Type: Bug
> Components: ldap
> Affects Versions: 2.0.0-M19
> Environment: centOS 6.5 with openldap and apacheds installed
> Reporter: linzhao
> Priority: Blocker
> Labels: LDAP
> Fix For: 2.0.0-M20
>
> Attachments: data.ldif, ordered-data.ldif, site.ldif, site_new.ldif,
> site_simple.ldif, site_topology_schema.ldif,
> site_topology_schema_simple.ldif, supercluster_partition.ldif, test.jpg
>
>
> In our system, we need to do data backup and restore for apacheds. For now,
> we use the ldapsearch and ldapadd command to do BR function. We use
> ldapsearch to backup apacheds data to be a ldif file and use ldapadd to
> restore the data. But when the ldif is a little big, I always found that the
> data can't be restored successfully, but the ladpadd command showed that the
> data can be added successfully. No exceptions for ldapadd command. But the
> restored data didn't exist in the node. This bug only happened when the ldif
> file is a little big. I mean if the data entry greater than 500 entries. But
> the node for backup and restore is using mavibot partition. Because I found
> so many problems for jdbm. So I change it to mavibot partition. Another
> question is that do you know is there some good way to do the data backup and
> restore for apacheds?
> May be my mavibot partition has some problems, so someone can tell me how to
> create a mavibot partition in APACHEDS? Because the mavibot parttion I
> created can't be viewed when click the "Open Configuration" in apacheds
> studio. Also I used unboundid JDK to insert many entries apacheds and the
> same problem happened. So someone can tell me how to config the mavibot
> partition on APACHEDS? That's may be very helpful.
> Below is the exceptions from apacheds when problems happened:
> [16:21:41] INFO [org.apache.directory.server.ldap.LdapServer] - Ldap service
> stopped.
> [16:21:41] WARN
> [org.apache.directory.server.core.shared.partition.DefaultPartitionNexus] -
> Failed to flush partition data out.
> org.apache.directory.api.ldap.model.exception.LdapOperationErrorException
> at
> org.apache.directory.server.core.partition.impl.btree.AbstractBTreePartition.saveContextCsn(AbstractBTreePartition.java:3364)
> at
> org.apache.directory.server.core.shared.partition.DefaultPartitionNexus.sync(DefaultPartitionNexus.java:319)
> at
> org.apache.directory.server.core.DefaultDirectoryService.shutdown(DefaultDirectoryService.java:1283)
> at org.apache.directory.server.ApacheDsService.stop(ApacheDsService.java:600)
> at
> org.apache.directory.server.wrapper.ApacheDsTanukiWrapper.stop(ApacheDsTanukiWrapper.java:97)
> at org.tanukisoftware.wrapper.WrapperManager$13.run(WrapperManager.java:3134)
> Caused by: java.lang.NullPointerException
> at
> org.apache.directory.server.core.partition.impl.btree.AbstractBTreePartition.saveContextCsn(AbstractBTreePartition.java:3350)
> ... 5 more
> [16:21:41] ERROR [org.apache.directory.server.wrapper.ApacheDsTanukiWrapper]
> - Failed to stop the service.
> org.apache.directory.api.util.exception.MultiException: ERR_265 Grouping many
> exceptions on root nexus sync()
> at
> org.apache.directory.server.core.shared.partition.DefaultPartitionNexus.sync(DefaultPartitionNexus.java:328)
> at
> org.apache.directory.server.core.DefaultDirectoryService.shutdown(DefaultDirectoryService.java:1283)
> at org.apache.directory.server.ApacheDsService.stop(ApacheDsService.java:600)
> at
> org.apache.directory.server.wrapper.ApacheDsTanukiWrapper.stop(ApacheDsTanukiWrapper.java:97)
> at org.tanukisoftware.wrapper.WrapperManager$13.run(WrapperManager.java:3134)
> Nested exceptions to follow:
> INFO | jvm 1 | 2015/02/02 17:11:06 | [17:11:06] WARN
> [org.apache.directory.server.ldap.LdapProtocolHandler] - Unexpected exception
> forcing session to close: sending disconnect notice to client.
> INFO | jvm 1 | 2015/02/02 17:11:06 | java.io.IOException: Connection reset by
> peer
> INFO | jvm 1 | 2015/02/02 17:11:06 | at
> sun.nio.ch.FileDispatcherImpl.read0(Native Method)
> INFO | jvm 1 | 2015/02/02 17:11:06 | at
> sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
> INFO | jvm 1 | 2015/02/02 17:11:06 | at
> sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
> INFO | jvm 1 | 2015/02/02 17:11:06 | at
> sun.nio.ch.IOUtil.read(IOUtil.java:197)
> INFO | jvm 1 | 2015/02/02 17:11:06 | at
> sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:379)
> INFO | jvm 1 | 2015/02/02 17:11:06 | at
> org.apache.mina.transport.socket.nio.NioProcessor.read(NioProcessor.java:311)
> INFO | jvm 1 | 2015/02/02 17:11:06 | at
> org.apache.mina.transport.socket.nio.NioProcessor.read(NioProcessor.java:45)
> INFO | jvm 1 | 2015/02/02 17:11:06 | at
> org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:694)
> INFO | jvm 1 | 2015/02/02 17:11:06 | at
> org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:668)
> INFO | jvm 1 | 2015/02/02 17:11:06 | at
> org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:657)
> INFO | jvm 1 | 2015/02/02 17:11:06 | at
> org.apache.mina.core.polling.AbstractPollingIoProcessor.access$600(AbstractPollingIoProcessor.java:67)
> INFO | jvm 1 | 2015/02/02 17:11:06 | at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:1121)
> INFO | jvm 1 | 2015/02/02 17:11:06 | at
> org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
> INFO | jvm 1 | 2015/02/02 17:11:06 | at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> INFO | jvm 1 | 2015/02/02 17:11:06 | at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> INFO | jvm 1 | 2015/02/02 17:11:06 | at java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
