diff --git a/CHANGES.txt b/CHANGES.txt index 8d4f6dd4161..cd57d844aa1 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -15,6 +15,8 @@ BUGFIXES: BOOKKEEPER-127: Make poms use official zookeeper 3.4.0 (ivank) BOOKKEEPER-120: Review BookKeeper client documentation (ivank) + + BOOKKEEPER-122: Review BookKeeper server documentation (fpj & ivank) bookkeeper-server/ diff --git a/bookkeeper-server/conf/bk_server.conf b/bookkeeper-server/conf/bk_server.conf index ccae1958af8..d005d01df64 100644 --- a/bookkeeper-server/conf/bk_server.conf +++ b/bookkeeper-server/conf/bk_server.conf @@ -40,7 +40,7 @@ ledgerDirectories=/tmp/bk-data # Ledger Manager Class # What kind of ledger manager is used to manage how ledgers are stored, managed -# and garbage collected. Try to read 'BookKeeper Overview' for detail info. +# and garbage collected. Try to read 'BookKeeper Internals' for detail info. # ledgerManagerType=flat # Root zookeeper path to store ledger metadata diff --git a/bookkeeper-server/src/main/java/org/apache/bookkeeper/client/AsyncCallback.java b/bookkeeper-server/src/main/java/org/apache/bookkeeper/client/AsyncCallback.java index 600dff0bd73..795bbcea21e 100644 --- a/bookkeeper-server/src/main/java/org/apache/bookkeeper/client/AsyncCallback.java +++ b/bookkeeper-server/src/main/java/org/apache/bookkeeper/client/AsyncCallback.java @@ -26,8 +26,8 @@ public interface AddCallback { * * @param rc * return code - * @param ledgerId - * ledger identifier + * @param lh + * ledger handle * @param entryId * entry identifier * @param ctx @@ -42,8 +42,8 @@ public interface CloseCallback { * * @param rc * return code - * @param ledgerId - * ledger identifier + * @param lh + * ledger handle * @param ctx * control object */ @@ -87,8 +87,8 @@ public interface ReadCallback { * * @param rc * return code - * @param ledgerId - * ledger identifier + * @param lh + * ledger handle * @param seq * sequence of entries * @param ctx diff --git a/bookkeeper-server/src/main/java/org/apache/bookkeeper/client/BookKeeper.java b/bookkeeper-server/src/main/java/org/apache/bookkeeper/client/BookKeeper.java index 04fbc05cb90..5bb37c3c218 100644 --- a/bookkeeper-server/src/main/java/org/apache/bookkeeper/client/BookKeeper.java +++ b/bookkeeper-server/src/main/java/org/apache/bookkeeper/client/BookKeeper.java @@ -251,7 +251,7 @@ public void asyncCreateLedger(int ensSize, int qSize, DigestType digestType, * digest type, either MAC or CRC32 * @param passwd * password - * @return + * @return a handle to the newly created ledger * @throws InterruptedException * @throws BKException */ @@ -262,13 +262,14 @@ public LedgerHandle createLedger(DigestType digestType, byte passwd[]) /** * Synchronous call to create ledger. Parameters match those of - * {@link #asyncCreateLedger(int, int, DigestType, byte[], CreateCallback, Object)} + * {@link #asyncCreateLedger(int, int, DigestType, byte[], + * AsyncCallback.CreateCallback, Object)} * * @param ensSize * @param qSize * @param digestType * @param passwd - * @return + * @return a handle to the newly created ledger * @throws InterruptedException * @throws BKException */ @@ -369,7 +370,7 @@ public void asyncOpenLedgerNoRecovery(long lId, DigestType digestType, byte pass * digest type, either MAC or CRC32 * @param passwd * password - * @return + * @return a handle to the open ledger * @throws InterruptedException * @throws BKException */ @@ -404,7 +405,7 @@ public LedgerHandle openLedger(long lId, DigestType digestType, byte passwd[]) * digest type, either MAC or CRC32 * @param passwd * password - * @return + * @return a handle to the open ledger * @throws InterruptedException * @throws BKException */ @@ -447,7 +448,7 @@ public void asyncDeleteLedger(long lId, DeleteCallback cb, Object ctx) { /** * Synchronous call to delete a ledger. Parameters match those of - * {@link #asyncDeleteLedger(long, DeleteCallback, Object)} + * {@link #asyncDeleteLedger(long, AsyncCallback.DeleteCallback, Object)} * * @param lId * ledgerId diff --git a/bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerHandle.java b/bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerHandle.java index 68490025134..8de20c9baa9 100644 --- a/bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerHandle.java +++ b/bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerHandle.java @@ -100,7 +100,7 @@ public class LedgerHandle { /** * Get the id of the current ledger * - * @return + * @return the id of the ledger */ public long getId() { return ledgerId; @@ -109,7 +109,7 @@ public long getId() { /** * Get the last confirmed entry id on this ledger * - * @return + * @return the last confirmed entry id */ public long getLastAddConfirmed() { return lastAddConfirmed; @@ -119,7 +119,7 @@ public long getLastAddConfirmed() { * Get the entry id of the last entry that has been enqueued for addition (but * may not have possibly been persited to the ledger) * - * @return + * @return the id of the last entry pushed */ public long getLastAddPushed() { return lastAddPushed; @@ -175,7 +175,7 @@ long addToLength(long delta) { /** * Returns the length of the ledger in bytes. * - * @return + * @return the length of the ledger in bytes */ public long getLength() { return this.length; diff --git a/bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerMetadata.java b/bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerMetadata.java index 63e95c06053..c353e466f70 100644 --- a/bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerMetadata.java +++ b/bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerMetadata.java @@ -133,11 +133,9 @@ long getNextEnsembleChange(long entryId) { } /** - * Generates a byte array based on a LedgerConfig object received. + * Generates a byte array of this object * - * @param config - * LedgerConfig object - * @return byte[] + * @return the metadata serialized into a byte array */ public byte[] serialize() { StringBuilder s = new StringBuilder(); diff --git a/doc/bookkeeperConfig.textile b/doc/bookkeeperConfig.textile index c02e283bcfe..13de05cc065 100644 --- a/doc/bookkeeperConfig.textile +++ b/doc/bookkeeperConfig.textile @@ -16,102 +16,42 @@ h1. Abstract This document contains information about deploying, administering and mantaining BookKeeper. It also discusses best practices and common problems. -As BookKeeper is still a prototype, this article is likely to change significantly over time. +h1. Running a BookKeeper instance -h1. System requirements +h2. System requirements -p. A typical BookKeeper installation comprises a set of bookies and a set of ZooKeeper replicas. The exact number of bookies depends on the quorum mode, desired throughput, and number of clients using this installation simultaneously. The minimum number of bookies is three for self-verifying (stores a message authentication code along with each entry) and four for generic (does not store a message authentication codewith each entry), and there is no upper limit on the number of bookies. Increasing the number of bookies, in fact, enables higher throughput. +p. A typical BookKeeper installation comprises a set of bookies and a set of ZooKeeper replicas. The exact number of bookies depends on the quorum mode, desired throughput, and number of clients using this installation simultaneously. The minimum number of bookies is three for self-verifying (stores a message authentication code along with each entry) and four for generic (does not store a message authentication code with each entry), and there is no upper limit on the number of bookies. Increasing the number of bookies will, in fact, enable higher throughput. -p. For performance, we require each server to have at least two disks. It is possible to run a bookie with a single disk, but performance will be significantly lower in this case. Of course, it works with one disk, but performance is significantly lower. +p. For performance, we require each server to have at least two disks. It is possible to run a bookie with a single disk, but performance will be significantly lower in this case. -p. For ZooKeeper, there is no constraint with respect to the number of replicas. Having a single machine running ZooKeeper in standalone mode is sufficient for BookKeeper. For resilience purposes, it might be a good idea to run ZooKeeper in quorum mode with multiple servers. Please refer to the ZooKeeper documentation for detail on how to configure ZooKeeper with multiple replicas +p. For ZooKeeper, there is no constraint with respect to the number of replicas. Having a single machine running ZooKeeper in standalone mode is sufficient for BookKeeper. For resilience purposes, it might be a good idea to run ZooKeeper in quorum mode with multiple servers. Please refer to the ZooKeeper documentation for detail on how to configure ZooKeeper with multiple replicas. -h1. Running bookies +h2. Running bookies p. To run a bookie, we execute the following command: - @ bookkeeper-server/bin/bookkeeper bookie +@bookkeeper-server/bin/bookkeeper bookie@ -p. The configuration parameters, which can be set in bookkeeper-server/conf/bkenv.sh +p. The configuration parameters can be set in bookkeeper-server/conf/bk_server.conf. -* BOOKIE_PORT: Port number that the bookie listens on; -* BOOKIE_ZOOKEEPER: Comma separated list of ZooKeeper servers with a hostname:port format; -* BOOKIE_TXN_LOGDIR: Path for Log Device (stores bookie write-ahead log); -* BOOKIE_DATA_DIR: Path for Ledger Device (stores ledger entries); +The important parameters are: + * @bookiePort@, Port number that the bookie listens on; + * @zkServers@, Comma separated list of ZooKeeper servers with a hostname:port format; + * @journalDir@, Path for Log Device (stores bookie write-ahead log); + * @ledgerDir@, Path for Ledger Device (stores ledger entries); -p. Ideally, @/path_to_log_device/@ and @/path_to_ledger_device/@ are each in a different device. +p. Ideally, @journalDir@ and @ledgerDir@ are each in a different device. See "BookKeeper Configuration Parameters":./bookkeeperConfigParams.html for a full list of configuration parameters. -h1. Bookie Configuration -p. Bookie server stores its data in multiple ledger directories and its journal files in a journal directory. Ideally, storing journal files in a separate directory than data files would increase throughput and decrease latency. +h3. Logging -h2. Journal Configuration +BookKeeper uses "slf4j":http://www.slf4j.org for logging, with the log4j bindings enabled by default. To enable logging from a bookie, create a log4j.properties file and point the environment variable BOOKIE_LOG_CONF to the configuration file. The path to the log4j.properties file must be absolute. -p. Journal directory has one kind of files in it: +@export BOOKIE_LOG_CONF=/tmp/log4j.properties@ +@bookkeeper-server/bin/bookkeeper bookie@ -* {timestamp}.txn - holds transactions executed in the bookie server. +h2. Setting up a test ensemble -p. Before persisting ledger index and data to disk, a bookie ensures that the transaction that represents the update is written to a journal in non-volatile storage. A new journal file is created using current timestamp when a bookie starts or an old journal file reaches its maximum size. +Sometimes it is useful to run a ensemble of bookies on your local machine for testing. We provide a utility for doing this. It will set up N bookies, and a zookeeper instance locally. The data on these bookies and of the zookeeper instance are not persisted over restarts, so obviously this should never be used in a production environment. To run a test ensemble of 10 bookies, do the following. -p. A bookie supports journal rolling to remove old journal files. In order to remove old journal files safely, bookie server records LastLogMark in Ledger Device, which indicates all updates (including index and data) before LastLogMark has been persisted to the Ledger Device. - -p. LastLogMark contains two parts: - -* LastLogId - indicates which journal file the transaction persisted. -* LastLogPos - indicates the position the transaction persisted in LastLogId journal file. - -p. You may use following settings to further fine tune the behavior of your Bookie servers. Currently these configuration settings are set using Java system properties. - -* journalMaxSizeMB -** journal file size limitation. when a journal reaches this limitation, it will be closed and new journal file be created. - -* journalMaxBackups -** how many old journal files whose id is less than LastLogMark 's journal id. - -bq. NOTE: keeping number of old journal files would be useful for manually recovery in special case. - -h1. ZooKeeper Metadata - -p. For BookKeeper, we require a ZooKeeper installation to store metadata, and to pass the list of ZooKeeper servers as parameter to the constructor of the BookKeeper class ( @org.apache.bookkeeper.client,BookKeeper@ ). To setup ZooKeeper, please check the "ZooKeeper documentation":index.html. - -p. BookKeeper provides two mechnaisms to organize its metadata in ZooKeeper. - -* FlatLedgerManager : All ledger metadata are placed as children in a single zookeeper path. -* HierarchicalLedgerManager : All ledger metadata are partitioned into 2-level znodes. - -h2. Flat Ledger Manager - -p. All ledgers' metadata are put in a single zookeeper path, created using zookeeper sequential node, which can ensure uniqueness of ledger id. Each ledger node is prefixed with 'L'. - -p. Bookie server manages its owned active ledgers in a hash map. So it is easy for bookie server to find what ledgers are deleted from zookeeper and garbage collect them. And its garbage collection flow is described as below: - -* Fetch all existing ledgers from zookeeper (*zkActiveLedgers*). -* Fetch all ledgers currently active within the Bookie (*bkActiveLedgers*). -* Loop over *bkActiveLedgers* to find those ledgers which do not exist in *zkActiveLedgers* and garbage collect them. - -h2. Hierarchical Ledger Manager - -p. Hierarchical Ledger Manager first obtains a global unique id from ZooKeeper using a EPHEMERAL_SEQUENTIAL znode. - -p. Since ZooKeeper sequential counter has a format of %10d -- that is 10 digits with 0 (zero) padding, i.e. "<path>0000000001", HierarchicalLedgerManager splits the generated id into 3 parts : - - @ {level1 (2 digits)}{level2 (4 digits)}{level3 (4 digits)} - -p. These 3 parts are used to form the actual ledger node path used to store ledger metadata: - - @ {ledgers_root_path}/{level1}/{level2}/L{level3} - -p. E.g. Ledger 0000000001 is split into 3 parts 00, 0000, 00001, which is stored in znode /{ledgers_root_path}/00/0000/L0001. So each znode could have at most 10000 ledgers, which avoids the problem of the child list being larger than the maximum ZooKeeper packet size. - -p. Bookie server manages its active ledgers in a sorted map, which simplifies access to active ledgers in a particular (level1, level2) partition. - -p. Garbage collection in bookie server is processed node by node as follows: - -* Fetching all level1 nodes, by calling zk#getChildren(ledgerRootPath). -** For each level1 nodes, fetching their level2 nodes : -** For each partition (level1, level2) : -*** Fetch all existed ledgers from zookeeper belonging to partition (level1, level2) (*zkActiveLedgers*). -*** Fetch all ledgers currently active in the bookie which belong to partition (level1, level2) (*bkActiveLedgers*). -*** Loop over *bkActiveLedgers* to find those ledgers which do not exist in *zkActiveLedgers*, and garbage collect them. - -bq. NOTE: Hierarchical Ledger Manager is more suitable to manage large number of ledgers existed in BookKeeper. +@bookkeeper-server/bin/bookkeeper localbookie 10@ diff --git a/doc/bookkeeperOverview.textile b/doc/bookkeeperOverview.textile index 1dca6ae68b1..81d014ffa6b 100644 --- a/doc/bookkeeperOverview.textile +++ b/doc/bookkeeperOverview.textile @@ -18,7 +18,7 @@ h1. BookKeeper introduction p. BookKeeper is a replicated service to reliably log streams of records. In BookKeeper, servers are "bookies", log streams are "ledgers", and each unit of a log (aka record) is a "ledger entry". BookKeeper is designed to be reliable; bookies, the servers that store ledgers, can crash, corrupt data, discard data, but as long as there are enough bookies behaving correctly the service as a whole behaves correctly. -p. The initial motivation for BookKeeper comes from the namenode of HDFS. Namenodes have to log operations in a reliable fashion so that recovery is possible in the case of crashes. We have found the applications for BookKeeper extend far beyond HDFS, however. Essentially, any application that requires an append storage can replace their implementations with BookKeeper. BookKeeper has the advantage of scaling throughput with the number of servers. +p. The initial motivation for BookKeeper comes from the namenode of HDFS. Namenodes have to log operations in a reliable fashion so that recovery is possible in the case of crashes. We have found the applications for BookKeeper extend far beyond HDFS, however. Essentially, any application that requires an append storage can replace their implementations with BookKeeper. BookKeeper has the advantage of writing efficiently, replicating for fault tolerance, and scaling throughput with the number of servers through striping. p. At a high level, a bookkeeper client receives entries from a client application and stores it to sets of bookies, and there are a few advantages in having such a service: @@ -100,7 +100,7 @@ p. We maintain this information in ZooKeeper. Bookies use ephemeral nodes to ind h1. Closing out ledgers -p. The process of closing out the ledger and finding the last ledger is difficult due to the durability guarantees of BookKeeper: +p. The process of closing out the ledger and finding the last entry is difficult due to the durability guarantees of BookKeeper: * If an entry has been successfully recorded, it must be readable. * If an entry is read once, it must always be available to be read. @@ -116,14 +116,16 @@ p. The trick to making everything work is to have a correct idea of a last entry # Find the highest consecutively recorded entry, _LR_ ; # Make sure that all entries between _LC_ and _LR_ are on a quorum of bookies; -h1. Data Management in Bookie Server +h1. Data Management in Bookies + +p. This section gives an overview of how a bookie manages its ledger fragments. h2. Basic -p. Bookie servers manage data in a log-structured way, which is implemented using three kind of files: +p. Bookies manage data in a log-structured way, which is implemented using three kind of files: -* _Journal_ : A journal file contains the BookKeeper transaction logs. Before any update takes place, a Bookie server ensures that a transaction describing the update is written to non-volatile storage. A new journal file is created once the Bookie server starts or the older journal file reaches the journal file size threshold. -* _Entry Log_ : An entry log file manages the written entries received from BookKeeper clients. Entries from different ledgers are aggregated and written sequentially, while their offsets are kept as pointers in _LedgerCache_ for fast lookup. A new entry log file is created once the Bookie server starts or the older entry log file reaches the entry log size threshold. Old entry log files are removed by the _Garbage Collector Thread_ once they are not associated with any active ledger. +* _Journal_ : A journal file contains the BookKeeper transaction logs. Before any update takes place, a bookie ensures that a transaction describing the update is written to non-volatile storage. A new journal file is created once the bookie starts or the older journal file reaches the journal file size threshold. +* _Entry Log_ : An entry log file manages the written entries received from BookKeeper clients. Entries from different ledgers are aggregated and written sequentially, while their offsets are kept as pointers in _LedgerCache_ for fast lookup. A new entry log file is created once the bookie starts or the older entry log file reaches the entry log size threshold. Old entry log files are removed by the _Garbage Collector Thread_ once they are not associated with any active ledger. * _Index File_ : An index file is created for each ledger, which comprises a header and several fixed-length index pages, recording the offsets of data stored in entry log files. p. Since updating index files would introduce random disk I/O, for performance consideration, index files are updated lazily by a _Sync Thread_ running in the background. Before index pages are persisted to disk, they are gathered in _LedgerCache_ for lookup. @@ -132,11 +134,11 @@ p. Since updating index files would introduce random disk I/O, for performance c h2. Add Entry -p. When a Bookie server receives entries from clients to be written, these entries will go through the following steps to be persisted to disk: +p. When a bookie receives entries from clients to be written, these entries will go through the following steps to be persisted to disk: # Append the entry in _Entry Log_, return its position { logId , offset } ; # Update the index of this entry in _Ledger Cache_ ; -# Append a transaction of update of this entry in _Journal_ ; +# Append a transaction corresponding to this entry update in _Journal_ ; # Respond to BookKeeper client ; * For performance reasons, _Entry Log_ buffers entries in memory and commit them in batches, while _Ledger Cache_ holds index pages in memory and flushes them lazily. We will discuss data flush and how to ensure data integrity in the following section 'Data Flush'. @@ -154,11 +156,11 @@ p. The data flush flow in _Sync Thread_ is as follows: # Records a _LastLogMark_ in memory. The _LastLogMark_ contains two parts: first one is _txnLogId_ (file id of a journal) and the second one is _txnLogPos_ (offset in a journal). The _LastLogMark_ indicates that those entries before it have been persisted to both index and entry log files. # Flushes dirty index pages from _LedgerCache_ to index file, and flushes entry log files to ensure all buffered entries in entry log files are persisted to disk. -#* Ideally, a Bookie server just needs to flush index pages and entry log files that contains entries before _LastLogMark_. There is no such information in _LedgerCache_ and _Entry Log_ mapping to journal files, though. Consequently, the thread flushes _LedgerCache_ and _Entry Log_ entirely here, and may flush entries after the _LastLogMark_. Flushing more is not a problem, though, just redundant. +#* Ideally, a bookie just needs to flush index pages and entry log files that contains entries before _LastLogMark_. There is no such information in _LedgerCache_ and _Entry Log_ mapping to journal files, though. Consequently, the thread flushes _LedgerCache_ and _Entry Log_ entirely here, and may flush entries after the _LastLogMark_. Flushing more is not a problem, though, just redundant. # Persists _LastLogMark_ to disk, which means entries added before _LastLogMark_ whose entry data and index page were also persisted to disk. It is the time to safely remove journal files created earlier than _txnLogId_. -#* If a Bookie server has crashed before persisting _LastLogMark_ to disk, it still has journal files containing entries for which index pages may not have been persisted. Consequently, when this Bookie server restarts, it inspects journal files to restore those entries; data isn't lost. +#* If the bookie has crashed before persisting _LastLogMark_ to disk, it still has journal files containing entries for which index pages may not have been persisted. Consequently, when this bookie restarts, it inspects journal files to restore those entries; data isn't lost. -p. Using the above data flush mechanism, it is safe for the _Sync Thread_ to skip data flushing when the Bookie server shuts down. However, in _Entry Logger_, it uses _BufferedChannel_ to write entries in batches and there might be data buffered in _BufferedChannel_ upon a shut down. Bookie server needs to ensure _Entry Logger_ flushes its buffered data during shutting down. Otherwise, _Entry Log_ files become corrupted with partial entries. +p. Using the above data flush mechanism, it is safe for the _Sync Thread_ to skip data flushing when the bookie shuts down. However, in _Entry Logger_, it uses _BufferedChannel_ to write entries in batches and there might be data buffered in _BufferedChannel_ upon a shut down. The bookie needs to ensure _Entry Logger_ flushes its buffered data during shutting down. Otherwise, _Entry Log_ files become corrupted with partial entries. p. As described above, _EntryLogger#flush_ is invoked in the following two cases: * in _Sync Thread_ : used to ensure entries added before _LastLogMark_ are persisted to disk. diff --git a/doc/bookkeeperStarted.textile b/doc/bookkeeperStarted.textile index 0d030b715c5..37233cd9d4c 100644 --- a/doc/bookkeeperStarted.textile +++ b/doc/bookkeeperStarted.textile @@ -32,7 +32,7 @@ p. BookKeeper provides a utility program to start a standalone ZooKeeper ensembl p. To start a local bookkeeper ensemble with 5 bookies: -@ bookkeeper-server/bin/bookkeeper localbookie 5 + @bookkeeper-server/bin/bookkeeper localbookie 5@ h1. Setting up bookies @@ -40,13 +40,13 @@ p. If you're bold and you want more than just running things locally, then you'l p. For each bookie, we need to execute a command like the following: - @ bookkeeper-server/bin/bookkeeper bookie + @bookkeeper-server/bin/bookkeeper bookie@ -p. This command will use the default directories for storing ledgers and the write ahead log, and will look for a zookeeper server on localhost:2181. To modify this you must edit bookkeeper-server/conf/bkenv.sh. BOOKIE_TXN_LOGDIR and BOOKIE_DATA_DIR should be configured to used different physical devices for best performance. BOOKIE_ZOOKEEPER should be a comma separated list of zookeeper servers. +p. This command will use the default directories for storing ledgers and the write ahead log, and will look for a zookeeper server on localhost:2181. See the "Admin Guide":./bookkeeperConfig.html for more details. p. To see the default values of these configuration variables, run: - @ bookkeeper-server/bin/bookkeeper help + @bookkeeper-server/bin/bookkeeper help@ h1. Setting up ZooKeeper @@ -60,14 +60,17 @@ h1. Example p. In the following excerpt of code, we: +# Open a bookkeeper client; # Create a ledger; # Write to the ledger; # Close the ledger; # Open the same ledger for reading; # Read from the ledger; # Close the ledger again; +# Close the bookkeeper client. -bc.. +

+BookKeeper bkc = new BookKeeper("localhost:2181");
 LedgerHandle lh = bkc.createLedger(ledgerPassword);
 ledgerId = lh.getId();
 ByteBuffer entry = ByteBuffer.allocate(4);
@@ -93,4 +96,5 @@ while(ls.hasMoreElements()){
 	Integer retrEntry = result.getInt();
 }
 lh.close();
-	    
+bkc.close();
+
\ No newline at end of file diff --git a/doc/index.textile b/doc/index.textile index a3138da0041..41a73d31e25 100644 --- a/doc/index.textile +++ b/doc/index.textile @@ -22,6 +22,9 @@ h1. Apache BookKeeper documentation * "Getting started":./bookkeeperStarted.html * "Programmer's Guide":./bookkeeperProgrammer.html * "Admin Guide":./bookkeeperConfig.html +* "Bookie Server Configuration Parameters":./bookkeeperConfigParams.html +* "BookKeeper Internals":./bookkeeperInternals.html +* "Bookie Recovery":./bookieRecovery.html * "Using BookKeeper stream library":./bookkeeperStream.html h1. Apache Hedwig documentation diff --git a/hedwig-client/src/main/java/org/apache/hedwig/util/CallbackUtils.java b/hedwig-client/src/main/java/org/apache/hedwig/util/CallbackUtils.java index 42187c4db23..8f0fda8166f 100644 --- a/hedwig-client/src/main/java/org/apache/hedwig/util/CallbackUtils.java +++ b/hedwig-client/src/main/java/org/apache/hedwig/util/CallbackUtils.java @@ -51,7 +51,7 @@ public class CallbackUtils { * failure (but before the final failure callback). Useful for * releasing resources, etc. as soon as we know the composite * operation is doomed. - * @return + * @return the generated callback */ public static Callback multiCallback(final int expected, final Callback cb, final Object ctx, final Logger logger, final String successMsg, final String failureMsg, diff --git a/pom.xml b/pom.xml index 5d68a8b7b06..32b48aea9be 100644 --- a/pom.xml +++ b/pom.xml @@ -63,7 +63,7 @@ 2.8 -exclude org.apache.hedwig.client.netty:org.apache.hedwig.client.benchmark:org.apache.hedwig.client.data:org.apache.hedwig.client.exceptions:org.apache.hedwig.client.handlers:org.apache.hedwig.client.ssl - org.apache.bookkeeper.client:org.apache.hedwig.client:org.apache.hedwig.util:org.apache.hedwig.protocol:org.apache.hedwig.exceptions + org.apache.bookkeeper.client:org.apache.bookkeeper.conf:org.apache.hedwig.client:org.apache.hedwig.util:org.apache.hedwig.protocol:org.apache.hedwig.exceptions Bookkeeper