Fix the typo of double the

bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/storage/ldb/DbLedgerStorage.java

@@ -119,7 +119,7 @@ public class DbLedgerStorage implements LedgerStorage {
     private int numberOfDirs;
     private List<SingleDirectoryDbLedgerStorage> ledgerStorageList;
 
-    // Keep 1 single Bookie GC thread so the the compactions from multiple individual directories are serialized
+    // Keep 1 single Bookie GC thread so the compactions from multiple individual directories are serialized
     private ScheduledExecutorService gcExecutor;
     private ExecutorService entryLoggerWriteExecutor = null;
     private ExecutorService entryLoggerFlushExecutor = null;

bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerHandle.java

@@ -113,7 +113,7 @@ private enum HandleState {
 
     /**
       * Last entryId which has been confirmed to be written durably to the bookies.
-      * This value is used by readers, the the LAC protocol
+      * This value is used by readers, the LAC protocol
       */
     volatile long lastAddConfirmed;
 
@@ -1382,7 +1382,7 @@ synchronized void updateLastConfirmed(long lac, long len) {
 
     /**
      * Obtains asynchronously the last confirmed write from a quorum of bookies. This
-     * call obtains the the last add confirmed each bookie has received for this ledger
+     * call obtains the last add confirmed each bookie has received for this ledger
      * and returns the maximum. If the ledger has been closed, the value returned by this
      * call may not correspond to the id of the last entry of the ledger, since it reads
      * the hint of bookies. Consequently, in the case the ledger has been closed, it may
@@ -1631,7 +1631,7 @@ boolean ready() {
 
     /**
      * Obtains synchronously the last confirmed write from a quorum of bookies. This call
-     * obtains the the last add confirmed each bookie has received for this ledger
+     * obtains the last add confirmed each bookie has received for this ledger
      * and returns the maximum. If the ledger has been closed, the value returned by this
      * call may not correspond to the id of the last entry of the ledger, since it reads
      * the hint of bookies. Consequently, in the case the ledger has been closed, it may

bookkeeper-server/src/main/java/org/apache/bookkeeper/client/api/ReadHandle.java

@@ -103,7 +103,7 @@ default LedgerEntries readUnconfirmed(long firstEntry, long lastEntry)
 
     /**
      * Obtains asynchronously the last confirmed write from a quorum of bookies. This
-     * call obtains the the last add confirmed each bookie has received for this ledger
+     * call obtains the last add confirmed each bookie has received for this ledger
      * and returns the maximum. If the ledger has been closed, the value returned by this
      * call may not correspond to the id of the last entry of the ledger, since it reads
      * the hint of bookies. Consequently, in the case the ledger has been closed, it may

site3/website/src/pages/bps/BP-31-durability.md

@@ -111,7 +111,7 @@ If ZK is completely wiped, but snapshots are available, restore ZK from snapshot
 If the data stays on the disk for long time(years), it is possible to experience silent data degradation on the disk. In the current scenario we will not identify this until the data is read by the application.
 
 ### End to end checksum
-Bookies never validate the payload checksum. If the the client’s socket has issues, it might corrupt the data (at the source) and it won’t be detected until client reads it back. That will be too late as the original write was successful for the application. Use efficient checksum mechanisms and enforce checksum validations on the bookie’s write path. If checksum validation fails, the the write itself will fail and application will be notified. 
+Bookies never validate the payload checksum. If the client’s socket has issues, it might corrupt the data (at the source) and it won’t be detected until client reads it back. That will be too late as the original write was successful for the application. Use efficient checksum mechanisms and enforce checksum validations on the bookie’s write path. If checksum validation fails, write itself will fail and application will be notified. 
 
 
 ## Test strategy to validate durability

site3/website/src/pages/bps/BP-41-bookieid.md

@@ -51,7 +51,7 @@ The serialized representation of a BookieSocketAddress, both for LedgerMetadata
 
 It is simply a pure refactor of Java interfaces.
 
-We have to introduce an internal API, **BookieAddressResolver**, that maps a *BookieId* to a *BookieSocketAddress*: the the client connectes to a Bookie it looks up the **current network address** using BookieAddressResolver.
+We have to introduce an internal API, **BookieAddressResolver**, that maps a *BookieId* to a *BookieSocketAddress*: the client connectes to a Bookie it looks up the **current network address** using BookieAddressResolver.
 
 ```
 interface BookieAddressResolver {

stream/clients/python/bookkeeper/common/timeout.py

@@ -140,7 +140,7 @@ class ExponentialTimeout(object):
 
     This is useful if a function is called multiple times. Each time the
     function is called this decorator will calculate a new timeout parameter
-    based on the the number of times the function has been called.
+    based on the number of times the function has been called.
 
     For example
 

stream/distributedlog/core/src/main/java/org/apache/distributedlog/ZooKeeperClient.java

@@ -393,7 +393,7 @@ public synchronized void closeInternal() {
     }
 
     /**
-     * Closes the the underlying zookeeper instance.
+     * Closes the underlying zookeeper instance.
      * Subsequent attempts to {@link #get} will fail
      */
     public synchronized void close() {