You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@distributedlog.apache.org by si...@apache.org on 2016/09/13 09:00:30 UTC
[51/64] [partial] incubator-distributedlog git commit: delete the
content from old site
delete the content from old site
Project: http://git-wip-us.apache.org/repos/asf/incubator-distributedlog/repo
Commit: http://git-wip-us.apache.org/repos/asf/incubator-distributedlog/commit/1bd00e9a
Tree: http://git-wip-us.apache.org/repos/asf/incubator-distributedlog/tree/1bd00e9a
Diff: http://git-wip-us.apache.org/repos/asf/incubator-distributedlog/diff/1bd00e9a
Branch: refs/heads/asf-site
Commit: 1bd00e9af798b8afc9b17fc301a22e8ce1adb9ad
Parents: 9ae6aa5
Author: Sijie Guo <si...@twitter.com>
Authored: Tue Sep 13 01:47:37 2016 -0700
Committer: Sijie Guo <si...@twitter.com>
Committed: Tue Sep 13 01:47:37 2016 -0700
----------------------------------------------------------------------
CNAME | 1 -
README.md | 37 -
_images/costmodel.png | Bin 35381 -> 0 bytes
_images/datamodel.png | Bin 51935 -> 0 bytes
_images/datamodel1.png | Bin 51935 -> 0 bytes
_images/distribution.png | Bin 16923 -> 0 bytes
_images/fencing.png | Bin 53642 -> 0 bytes
_images/globalreplicatedlog.png | Bin 111734 -> 0 bytes
_images/lacprotocol.png | Bin 48746 -> 0 bytes
_images/logsegments.png | Bin 14238 -> 0 bytes
_images/pubsub.png | Bin 443154 -> 0 bytes
_images/readrequests.png | Bin 29553 -> 0 bytes
_images/requestflow.png | Bin 72989 -> 0 bytes
_images/requestrouting.png | Bin 40990 -> 0 bytes
_images/softwarestack.png | Bin 76557 -> 0 bytes
_images/softwarestack1.png | Bin 76557 -> 0 bytes
_sources/api/core.txt | 471 --
_sources/api/main.txt | 9 -
_sources/api/practice.txt | 76 -
_sources/api/proxy.txt | 74 -
_sources/architecture/main.txt | 160 -
_sources/basics/introduction.txt | 120 -
_sources/basics/main.txt | 8 -
_sources/basics/quickstart.txt | 106 -
_sources/basics/usecases.txt | 19 -
_sources/configuration/client.txt | 97 -
_sources/configuration/core.txt | 422 --
_sources/configuration/main.txt | 20 -
_sources/configuration/perlog.txt | 127 -
_sources/configuration/proxy.txt | 69 -
_sources/considerations/main.txt | 64 -
_sources/design/main.txt | 212 -
_sources/developer/main.txt | 8 -
_sources/developer/release.txt | 21 -
_sources/download.txt | 45 -
_sources/faq.txt | 2 -
_sources/globalreplicatedlog/main.txt | 99 -
_sources/implementation/core.txt | 0
_sources/implementation/main.txt | 9 -
_sources/implementation/storage.txt | 313 -
_sources/implementation/writeproxy.txt | 0
_sources/index.txt | 23 -
_sources/operations/bookkeeper.txt | 193 -
_sources/operations/deployment.txt | 534 --
_sources/operations/hardware.txt | 120 -
_sources/operations/main.txt | 13 -
_sources/operations/monitoring.txt | 378 --
_sources/operations/operations.txt | 204 -
_sources/operations/performance.txt | 4 -
_sources/operations/zookeeper.txt | 88 -
_sources/performance/main.txt | 4 -
_sources/references/configuration.txt | 2 -
_sources/references/features.txt | 30 -
_sources/references/main.txt | 11 -
_sources/references/metrics.txt | 480 --
_sources/tutorials/analytics-mapreduce.txt | 1 -
_sources/tutorials/basic-1.txt | 1 -
_sources/tutorials/basic-2.txt | 1 -
_sources/tutorials/basic-3.txt | 1 -
_sources/tutorials/basic-4.txt | 1 -
_sources/tutorials/basic-5.txt | 1 -
_sources/tutorials/basic-6.txt | 1 -
_sources/tutorials/main.txt | 36 -
_sources/tutorials/messaging-1.txt | 1 -
_sources/tutorials/messaging-2.txt | 1 -
_sources/tutorials/messaging-3.txt | 1 -
_sources/tutorials/messaging-4.txt | 1 -
_sources/tutorials/messaging-5.txt | 1 -
_static/Twitter_logo_blue.png | Bin 9930 -> 0 bytes
_static/ajax-loader.gif | Bin 673 -> 0 bytes
_static/basic.css | 536 --
_static/bootstrap-3.1.0/css/bootstrap-theme.css | 347 --
.../bootstrap-3.1.0/css/bootstrap-theme.css.map | 1 -
.../bootstrap-3.1.0/css/bootstrap-theme.min.css | 7 -
_static/bootstrap-3.1.0/css/bootstrap.css | 5831 ------------------
_static/bootstrap-3.1.0/css/bootstrap.css.map | 1 -
_static/bootstrap-3.1.0/css/bootstrap.min.css | 7 -
.../fonts/glyphicons-halflings-regular.eot | Bin 20290 -> 0 bytes
.../fonts/glyphicons-halflings-regular.svg | 229 -
.../fonts/glyphicons-halflings-regular.ttf | Bin 41236 -> 0 bytes
.../fonts/glyphicons-halflings-regular.woff | Bin 23292 -> 0 bytes
_static/bootstrap-3.1.0/js/bootstrap.js | 1951 ------
_static/bootstrap-3.1.0/js/bootstrap.min.js | 6 -
_static/comment-bright.png | Bin 3500 -> 0 bytes
_static/comment-close.png | Bin 3578 -> 0 bytes
_static/comment.png | Bin 3445 -> 0 bytes
_static/css/docbird-xs.css | 102 -
_static/css/docbird.css | 790 ---
_static/css/featherlight.min.css | 8 -
_static/css/jquery.rateyo.min.css | 1 -
_static/css/selection-sharer.css | 203 -
_static/docbird-logo.png | Bin 23735 -> 0 bytes
_static/docbird-logo.svg | 155 -
_static/docbird.ico | Bin 32038 -> 0 bytes
_static/doctools.js | 235 -
_static/dotnoise-light-grey.png | Bin 6295 -> 0 bytes
_static/down-pressed.png | Bin 368 -> 0 bytes
_static/down.png | Bin 363 -> 0 bytes
_static/file.png | Bin 392 -> 0 bytes
_static/jquery.js | 2 -
_static/js/bootstrap-docbird.js | 64 -
_static/js/docbird.js | 61 -
_static/js/featherlight.min.js | 8 -
_static/js/ifvisible.js | 304 -
_static/js/jquery-1.11.0.min.js | 4 -
_static/js/jquery-fix.js | 2 -
_static/js/jquery.rateyo.min.js | 4 -
_static/js/js.cookie.js | 139 -
_static/js/rateyo.LICENSE | 21 -
_static/js/selection-sharer.js | 303 -
_static/js/timeme.js | 160 -
_static/mag.png | Bin 815 -> 0 bytes
_static/minus.png | Bin 199 -> 0 bytes
_static/override.css | 0
_static/plus.png | Bin 199 -> 0 bytes
_static/pygments.css | 65 -
_static/searchtools.js | 622 --
_static/underscore.js | 31 -
_static/up-pressed.png | Bin 372 -> 0 bytes
_static/up.png | Bin 363 -> 0 bytes
_static/websupport.js | 808 ---
api/core.html | 1162 ----
api/main.html | 545 --
api/practice.html | 629 --
api/proxy.html | 635 --
architecture/main.html | 669 --
basics/introduction.html | 639 --
basics/main.html | 544 --
basics/quickstart.html | 628 --
configuration/client.html | 631 --
configuration/core.html | 976 ---
configuration/main.html | 550 --
configuration/perlog.html | 689 ---
configuration/proxy.html | 603 --
considerations/main.html | 593 --
content/blog/index.html | 185 +
content/coming-soon.html | 185 +
content/community/index.html | 251 +
content/community/team/index.html | 330 +
content/contribute/index.html | 274 +
content/css/main.css | 457 ++
content/css/theme.css | 21 +
content/docs/latest/admin_guide/bookkeeper.html | 666 ++
content/docs/latest/admin_guide/hardware.html | 601 ++
content/docs/latest/admin_guide/main.html | 434 ++
content/docs/latest/admin_guide/monitoring.html | 823 +++
content/docs/latest/admin_guide/operations.html | 671 ++
.../docs/latest/admin_guide/performance.html | 500 ++
content/docs/latest/admin_guide/vagrant.rst | 18 +
content/docs/latest/admin_guide/zookeeper.html | 552 ++
content/docs/latest/basics/introduction.html | 705 +++
content/docs/latest/css/main.css | 457 ++
content/docs/latest/css/theme.css | 21 +
content/docs/latest/deployment/cluster.html | 956 +++
content/docs/latest/deployment/docker.html | 407 ++
.../bootstrap/glyphicons-halflings-regular.eot | Bin 0 -> 20127 bytes
.../bootstrap/glyphicons-halflings-regular.svg | 288 +
.../bootstrap/glyphicons-halflings-regular.ttf | Bin 0 -> 45404 bytes
.../bootstrap/glyphicons-halflings-regular.woff | Bin 0 -> 23424 bytes
.../glyphicons-halflings-regular.woff2 | Bin 0 -> 18028 bytes
content/docs/latest/images/costmodel.png | Bin 0 -> 35381 bytes
content/docs/latest/images/datamodel.png | Bin 0 -> 51935 bytes
.../latest/images/distributedlog_logo_l.png | Bin 0 -> 20791 bytes
.../images/distributedlog_logo_navbar.png | Bin 0 -> 9195 bytes
.../latest/images/distributedlog_logo_s.png | Bin 0 -> 2006 bytes
content/docs/latest/images/distribution.png | Bin 0 -> 16923 bytes
content/docs/latest/images/favicon.ico | Bin 0 -> 1660 bytes
content/docs/latest/images/fencing.png | Bin 0 -> 53642 bytes
.../docs/latest/images/globalreplicatedlog.png | Bin 0 -> 111734 bytes
content/docs/latest/images/lacprotocol.png | Bin 0 -> 48746 bytes
content/docs/latest/images/logsegments.png | Bin 0 -> 14238 bytes
content/docs/latest/images/pubsub.png | Bin 0 -> 443154 bytes
content/docs/latest/images/readrequests.png | Bin 0 -> 29553 bytes
content/docs/latest/images/requestflow.png | Bin 0 -> 72989 bytes
content/docs/latest/images/requestrouting.png | Bin 0 -> 40990 bytes
content/docs/latest/images/softwarestack.png | Bin 0 -> 76557 bytes
content/docs/latest/index.html | 416 ++
content/docs/latest/js/bootstrap-sprockets.js | 12 +
content/docs/latest/js/bootstrap.js | 2363 +++++++
content/docs/latest/js/bootstrap.min.js | 7 +
content/docs/latest/js/bootstrap/affix.js | 162 +
content/docs/latest/js/bootstrap/alert.js | 94 +
content/docs/latest/js/bootstrap/button.js | 120 +
content/docs/latest/js/bootstrap/carousel.js | 237 +
content/docs/latest/js/bootstrap/collapse.js | 211 +
content/docs/latest/js/bootstrap/dropdown.js | 165 +
content/docs/latest/js/bootstrap/modal.js | 337 +
content/docs/latest/js/bootstrap/popover.js | 108 +
content/docs/latest/js/bootstrap/scrollspy.js | 172 +
content/docs/latest/js/bootstrap/tab.js | 155 +
content/docs/latest/js/bootstrap/tooltip.js | 514 ++
content/docs/latest/js/bootstrap/transition.js | 59 +
content/docs/latest/performance/main.html | 360 ++
content/docs/latest/start/building.html | 423 ++
content/docs/latest/start/download.html | 441 ++
content/docs/latest/start/quickstart.html | 459 ++
content/docs/latest/styles/site.css | 5811 +++++++++++++++++
.../latest/tutorials/analytics-mapreduce.html | 550 ++
content/docs/latest/tutorials/basic-1.html | 593 ++
content/docs/latest/tutorials/basic-2.html | 561 ++
content/docs/latest/tutorials/basic-3.html | 625 ++
content/docs/latest/tutorials/basic-4.html | 582 ++
content/docs/latest/tutorials/basic-5.html | 559 ++
content/docs/latest/tutorials/basic-6.html | 672 ++
content/docs/latest/tutorials/main.html | 431 ++
content/docs/latest/tutorials/messaging-1.html | 526 ++
content/docs/latest/tutorials/messaging-2.html | 564 ++
content/docs/latest/tutorials/messaging-3.html | 455 ++
content/docs/latest/tutorials/messaging-4.html | 376 ++
content/docs/latest/tutorials/messaging-5.html | 370 ++
.../tutorials/replicatedstatemachines.html | 360 ++
content/docs/latest/user_guide/api/core.html | 1034 ++++
content/docs/latest/user_guide/api/main.html | 594 ++
.../docs/latest/user_guide/api/practice.html | 666 ++
content/docs/latest/user_guide/api/proxy.html | 662 ++
.../latest/user_guide/architecture/main.html | 748 +++
.../latest/user_guide/configuration/client.html | 694 +++
.../latest/user_guide/configuration/core.html | 1057 ++++
.../latest/user_guide/configuration/main.html | 600 ++
.../latest/user_guide/configuration/perlog.html | 728 +++
.../latest/user_guide/configuration/proxy.html | 666 ++
.../latest/user_guide/considerations/main.html | 639 ++
content/docs/latest/user_guide/design/main.html | 789 +++
.../user_guide/globalreplicatedlog/main.html | 677 ++
.../latest/user_guide/implementation/core.html | 359 ++
.../latest/user_guide/implementation/main.html | 588 ++
.../user_guide/implementation/storage.html | 890 +++
.../user_guide/implementation/writeproxy.html | 359 ++
content/docs/latest/user_guide/main.html | 528 ++
.../latest/user_guide/references/features.html | 626 ++
.../docs/latest/user_guide/references/main.html | 591 ++
.../latest/user_guide/references/metrics.html | 950 +++
content/faq/index.html | 196 +
content/feed.xml | 14 +
.../bootstrap/glyphicons-halflings-regular.eot | Bin 0 -> 20127 bytes
.../bootstrap/glyphicons-halflings-regular.svg | 288 +
.../bootstrap/glyphicons-halflings-regular.ttf | Bin 0 -> 45404 bytes
.../bootstrap/glyphicons-halflings-regular.woff | Bin 0 -> 23424 bytes
.../glyphicons-halflings-regular.woff2 | Bin 0 -> 18028 bytes
content/images/distributedlog_logo_l.png | Bin 0 -> 20791 bytes
content/images/distributedlog_logo_navbar.png | Bin 0 -> 9195 bytes
content/images/distributedlog_logo_s.png | Bin 0 -> 2006 bytes
content/images/favicon.ico | Bin 0 -> 1660 bytes
content/index.html | 304 +
content/js/bootstrap-sprockets.js | 12 +
content/js/bootstrap.js | 2363 +++++++
content/js/bootstrap.min.js | 7 +
content/js/bootstrap/affix.js | 162 +
content/js/bootstrap/alert.js | 94 +
content/js/bootstrap/button.js | 120 +
content/js/bootstrap/carousel.js | 237 +
content/js/bootstrap/collapse.js | 211 +
content/js/bootstrap/dropdown.js | 165 +
content/js/bootstrap/modal.js | 337 +
content/js/bootstrap/popover.js | 108 +
content/js/bootstrap/scrollspy.js | 172 +
content/js/bootstrap/tab.js | 155 +
content/js/bootstrap/tooltip.js | 514 ++
content/js/bootstrap/transition.js | 59 +
content/presentations/index.html | 10 +
content/project/presentations/index.html | 194 +
content/styles/site.css | 5811 +++++++++++++++++
content/team/index.html | 10 +
design/main.html | 714 ---
developer/main.html | 543 --
developer/release.html | 554 --
doctrees/api/core.doctree | Bin 71808 -> 0 bytes
doctrees/api/main.doctree | Bin 2876 -> 0 bytes
doctrees/api/practice.doctree | Bin 15973 -> 0 bytes
doctrees/api/proxy.doctree | Bin 11660 -> 0 bytes
doctrees/architecture/main.doctree | Bin 46525 -> 0 bytes
doctrees/basics/introduction.doctree | Bin 30685 -> 0 bytes
doctrees/basics/main.doctree | Bin 2929 -> 0 bytes
doctrees/basics/quickstart.doctree | Bin 18057 -> 0 bytes
doctrees/configuration/client.doctree | Bin 28627 -> 0 bytes
doctrees/configuration/core.doctree | Bin 140458 -> 0 bytes
doctrees/configuration/main.doctree | Bin 5420 -> 0 bytes
doctrees/configuration/perlog.doctree | Bin 34825 -> 0 bytes
doctrees/configuration/proxy.doctree | Bin 28322 -> 0 bytes
doctrees/considerations/main.doctree | Bin 17116 -> 0 bytes
doctrees/design/main.doctree | Bin 62540 -> 0 bytes
doctrees/developer/main.doctree | Bin 2880 -> 0 bytes
doctrees/developer/release.doctree | Bin 6488 -> 0 bytes
doctrees/download.doctree | Bin 19152 -> 0 bytes
doctrees/environment.pickle | Bin 145209 -> 0 bytes
doctrees/faq.doctree | Bin 2453 -> 0 bytes
doctrees/globalreplicatedlog/main.doctree | Bin 25906 -> 0 bytes
doctrees/implementation/core.doctree | Bin 2181 -> 0 bytes
doctrees/implementation/main.doctree | Bin 2990 -> 0 bytes
doctrees/implementation/storage.doctree | Bin 58369 -> 0 bytes
doctrees/implementation/writeproxy.doctree | Bin 2195 -> 0 bytes
doctrees/index.doctree | Bin 22781 -> 0 bytes
doctrees/operations/bookkeeper.doctree | Bin 37415 -> 0 bytes
doctrees/operations/deployment.doctree | Bin 80255 -> 0 bytes
doctrees/operations/hardware.doctree | Bin 23112 -> 0 bytes
doctrees/operations/main.doctree | Bin 3161 -> 0 bytes
doctrees/operations/monitoring.doctree | Bin 37937 -> 0 bytes
doctrees/operations/operations.doctree | Bin 30312 -> 0 bytes
doctrees/operations/performance.doctree | Bin 2791 -> 0 bytes
doctrees/operations/zookeeper.doctree | Bin 14812 -> 0 bytes
doctrees/performance/main.doctree | Bin 2715 -> 0 bytes
doctrees/references/configuration.doctree | Bin 2569 -> 0 bytes
doctrees/references/features.doctree | Bin 19263 -> 0 bytes
doctrees/references/main.doctree | Bin 3302 -> 0 bytes
doctrees/references/metrics.doctree | Bin 89374 -> 0 bytes
doctrees/tutorials/analytics-mapreduce.doctree | Bin 28745 -> 0 bytes
doctrees/tutorials/basic-1.doctree | Bin 30315 -> 0 bytes
doctrees/tutorials/basic-2.doctree | Bin 28872 -> 0 bytes
doctrees/tutorials/basic-3.doctree | Bin 34015 -> 0 bytes
doctrees/tutorials/basic-4.doctree | Bin 28731 -> 0 bytes
doctrees/tutorials/basic-5.doctree | Bin 25643 -> 0 bytes
doctrees/tutorials/basic-6.doctree | Bin 33562 -> 0 bytes
doctrees/tutorials/main.doctree | Bin 12365 -> 0 bytes
doctrees/tutorials/messaging-1.doctree | Bin 28523 -> 0 bytes
doctrees/tutorials/messaging-2.doctree | Bin 29553 -> 0 bytes
doctrees/tutorials/messaging-3.doctree | Bin 14031 -> 0 bytes
doctrees/tutorials/messaging-4.doctree | Bin 5733 -> 0 bytes
doctrees/tutorials/messaging-5.doctree | Bin 3745 -> 0 bytes
download.html | 578 --
faq.html | 537 --
genindex.html | 525 --
globalreplicatedlog/main.html | 621 --
html/.buildinfo | 4 -
html/_images/costmodel.png | Bin 35381 -> 0 bytes
html/_images/datamodel.png | Bin 51935 -> 0 bytes
html/_images/datamodel1.png | Bin 51935 -> 0 bytes
html/_images/distribution.png | Bin 16923 -> 0 bytes
html/_images/fencing.png | Bin 53642 -> 0 bytes
html/_images/globalreplicatedlog.png | Bin 111734 -> 0 bytes
html/_images/lacprotocol.png | Bin 48746 -> 0 bytes
html/_images/logsegments.png | Bin 14238 -> 0 bytes
html/_images/pubsub.png | Bin 443154 -> 0 bytes
html/_images/readrequests.png | Bin 29553 -> 0 bytes
html/_images/requestflow.png | Bin 72989 -> 0 bytes
html/_images/requestrouting.png | Bin 40990 -> 0 bytes
html/_images/softwarestack.png | Bin 76557 -> 0 bytes
html/_images/softwarestack1.png | Bin 76557 -> 0 bytes
html/_sources/api/core.txt | 471 --
html/_sources/api/main.txt | 9 -
html/_sources/api/practice.txt | 76 -
html/_sources/api/proxy.txt | 74 -
html/_sources/architecture/main.txt | 160 -
html/_sources/basics/introduction.txt | 120 -
html/_sources/basics/main.txt | 8 -
html/_sources/basics/quickstart.txt | 106 -
html/_sources/basics/usecases.txt | 19 -
html/_sources/configuration/client.txt | 97 -
html/_sources/configuration/core.txt | 422 --
html/_sources/configuration/main.txt | 20 -
html/_sources/configuration/perlog.txt | 127 -
html/_sources/configuration/proxy.txt | 69 -
html/_sources/considerations/main.txt | 64 -
html/_sources/design/main.txt | 212 -
html/_sources/developer/main.txt | 8 -
html/_sources/developer/release.txt | 21 -
html/_sources/download.txt | 45 -
html/_sources/faq.txt | 2 -
html/_sources/globalreplicatedlog/main.txt | 99 -
html/_sources/implementation/core.txt | 0
html/_sources/implementation/main.txt | 9 -
html/_sources/implementation/storage.txt | 313 -
html/_sources/implementation/writeproxy.txt | 0
html/_sources/index.txt | 23 -
html/_sources/operations/bookkeeper.txt | 193 -
html/_sources/operations/deployment.txt | 534 --
html/_sources/operations/hardware.txt | 120 -
html/_sources/operations/main.txt | 13 -
html/_sources/operations/monitoring.txt | 378 --
html/_sources/operations/operations.txt | 204 -
html/_sources/operations/performance.txt | 4 -
html/_sources/operations/zookeeper.txt | 88 -
html/_sources/performance/main.txt | 4 -
html/_sources/references/configuration.txt | 2 -
html/_sources/references/features.txt | 30 -
html/_sources/references/main.txt | 11 -
html/_sources/references/metrics.txt | 480 --
html/_sources/tutorials/analytics-mapreduce.txt | 1 -
html/_sources/tutorials/basic-1.txt | 1 -
html/_sources/tutorials/basic-2.txt | 1 -
html/_sources/tutorials/basic-3.txt | 1 -
html/_sources/tutorials/basic-4.txt | 1 -
html/_sources/tutorials/basic-5.txt | 1 -
html/_sources/tutorials/basic-6.txt | 1 -
html/_sources/tutorials/main.txt | 36 -
html/_sources/tutorials/messaging-1.txt | 1 -
html/_sources/tutorials/messaging-2.txt | 1 -
html/_sources/tutorials/messaging-3.txt | 1 -
html/_sources/tutorials/messaging-4.txt | 1 -
html/_sources/tutorials/messaging-5.txt | 1 -
html/_static/Twitter_logo_blue.png | Bin 9930 -> 0 bytes
html/_static/ajax-loader.gif | Bin 673 -> 0 bytes
html/_static/basic.css | 536 --
.../bootstrap-3.1.0/css/bootstrap-theme.css | 347 --
.../bootstrap-3.1.0/css/bootstrap-theme.css.map | 1 -
.../bootstrap-3.1.0/css/bootstrap-theme.min.css | 7 -
html/_static/bootstrap-3.1.0/css/bootstrap.css | 5831 ------------------
.../bootstrap-3.1.0/css/bootstrap.css.map | 1 -
.../bootstrap-3.1.0/css/bootstrap.min.css | 7 -
.../fonts/glyphicons-halflings-regular.eot | Bin 20290 -> 0 bytes
.../fonts/glyphicons-halflings-regular.svg | 229 -
.../fonts/glyphicons-halflings-regular.ttf | Bin 41236 -> 0 bytes
.../fonts/glyphicons-halflings-regular.woff | Bin 23292 -> 0 bytes
html/_static/bootstrap-3.1.0/js/bootstrap.js | 1951 ------
.../_static/bootstrap-3.1.0/js/bootstrap.min.js | 6 -
html/_static/comment-bright.png | Bin 3500 -> 0 bytes
html/_static/comment-close.png | Bin 3578 -> 0 bytes
html/_static/comment.png | Bin 3445 -> 0 bytes
html/_static/css/docbird-xs.css | 102 -
html/_static/css/docbird.css | 790 ---
html/_static/css/featherlight.min.css | 8 -
html/_static/css/jquery.rateyo.min.css | 1 -
html/_static/css/selection-sharer.css | 203 -
html/_static/docbird-logo.png | Bin 23735 -> 0 bytes
html/_static/docbird-logo.svg | 155 -
html/_static/docbird.ico | Bin 32038 -> 0 bytes
html/_static/doctools.js | 235 -
html/_static/dotnoise-light-grey.png | Bin 6295 -> 0 bytes
html/_static/down-pressed.png | Bin 368 -> 0 bytes
html/_static/down.png | Bin 363 -> 0 bytes
html/_static/file.png | Bin 392 -> 0 bytes
html/_static/jquery.js | 2 -
html/_static/js/bootstrap-docbird.js | 64 -
html/_static/js/docbird.js | 61 -
html/_static/js/featherlight.min.js | 8 -
html/_static/js/ifvisible.js | 304 -
html/_static/js/jquery-1.11.0.min.js | 4 -
html/_static/js/jquery-fix.js | 2 -
html/_static/js/jquery.rateyo.min.js | 4 -
html/_static/js/js.cookie.js | 139 -
html/_static/js/rateyo.LICENSE | 21 -
html/_static/js/selection-sharer.js | 303 -
html/_static/js/timeme.js | 160 -
html/_static/mag.png | Bin 815 -> 0 bytes
html/_static/minus.png | Bin 199 -> 0 bytes
html/_static/override.css | 0
html/_static/plus.png | Bin 199 -> 0 bytes
html/_static/pygments.css | 65 -
html/_static/searchtools.js | 622 --
html/_static/underscore.js | 31 -
html/_static/up-pressed.png | Bin 372 -> 0 bytes
html/_static/up.png | Bin 363 -> 0 bytes
html/_static/websupport.js | 808 ---
html/api/core.html | 1162 ----
html/api/main.html | 545 --
html/api/practice.html | 629 --
html/api/proxy.html | 635 --
html/architecture/main.html | 669 --
html/basics/introduction.html | 639 --
html/basics/main.html | 544 --
html/basics/quickstart.html | 628 --
html/configuration/client.html | 631 --
html/configuration/core.html | 976 ---
html/configuration/main.html | 550 --
html/configuration/perlog.html | 689 ---
html/configuration/proxy.html | 603 --
html/considerations/main.html | 593 --
html/design/main.html | 714 ---
html/developer/main.html | 543 --
html/developer/release.html | 554 --
html/download.html | 578 --
html/faq.html | 537 --
html/genindex.html | 525 --
html/globalreplicatedlog/main.html | 621 --
html/implementation/core.html | 536 --
html/implementation/main.html | 543 --
html/implementation/storage.html | 969 ---
html/implementation/writeproxy.html | 536 --
html/index.html | 714 ---
html/objects.inv | Bin 210 -> 0 bytes
html/operations/bookkeeper.html | 722 ---
html/operations/deployment.html | 1111 ----
html/operations/hardware.html | 633 --
html/operations/main.html | 549 --
html/operations/monitoring.html | 993 ---
html/operations/operations.html | 742 ---
html/operations/performance.html | 540 --
html/operations/zookeeper.html | 611 --
html/performance/main.html | 539 --
html/references/configuration.html | 539 --
html/references/features.html | 565 --
html/references/main.html | 566 --
html/references/metrics.html | 858 ---
html/search.html | 552 --
html/searchindex.js | 1 -
html/tutorials/analytics-mapreduce.html | 828 ---
html/tutorials/basic-1.html | 789 ---
html/tutorials/basic-2.html | 753 ---
html/tutorials/basic-3.html | 840 ---
html/tutorials/basic-4.html | 785 ---
html/tutorials/basic-5.html | 744 ---
html/tutorials/basic-6.html | 978 ---
html/tutorials/main.html | 579 --
html/tutorials/messaging-1.html | 754 ---
html/tutorials/messaging-2.html | 806 ---
html/tutorials/messaging-3.html | 644 --
html/tutorials/messaging-4.html | 548 --
html/tutorials/messaging-5.html | 539 --
implementation/core.html | 536 --
implementation/main.html | 543 --
implementation/storage.html | 969 ---
implementation/writeproxy.html | 536 --
index.html | 714 ---
objects.inv | Bin 210 -> 0 bytes
operations/bookkeeper.html | 722 ---
operations/deployment.html | 1111 ----
operations/hardware.html | 633 --
operations/main.html | 549 --
operations/monitoring.html | 993 ---
operations/operations.html | 742 ---
operations/performance.html | 540 --
operations/zookeeper.html | 611 --
performance/main.html | 539 --
references/configuration.html | 539 --
references/features.html | 565 --
references/main.html | 566 --
references/metrics.html | 858 ---
search.html | 552 --
searchindex.js | 1 -
tutorials/analytics-mapreduce.html | 828 ---
tutorials/basic-1.html | 789 ---
tutorials/basic-2.html | 753 ---
tutorials/basic-3.html | 840 ---
tutorials/basic-4.html | 785 ---
tutorials/basic-5.html | 744 ---
tutorials/basic-6.html | 978 ---
tutorials/main.html | 579 --
tutorials/messaging-1.html | 754 ---
tutorials/messaging-2.html | 806 ---
tutorials/messaging-3.html | 644 --
tutorials/messaging-4.html | 548 --
tutorials/messaging-5.html | 539 --
531 files changed, 54640 insertions(+), 107366 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/incubator-distributedlog/blob/1bd00e9a/CNAME
----------------------------------------------------------------------
diff --git a/CNAME b/CNAME
deleted file mode 100644
index 1d5ea97..0000000
--- a/CNAME
+++ /dev/null
@@ -1 +0,0 @@
-distributedlog.io
http://git-wip-us.apache.org/repos/asf/incubator-distributedlog/blob/1bd00e9a/README.md
----------------------------------------------------------------------
diff --git a/README.md b/README.md
deleted file mode 100644
index c09deb2..0000000
--- a/README.md
+++ /dev/null
@@ -1,37 +0,0 @@
-## Overview
-
-DistributedLog (DL) is a high-performance, replicated log service, offering durability, replication and strong consistency
-as essentials for building reliable distributed systems.
-
-#### High Performance
-
-DL is able to provide milliseconds latency on durable writes with large number of concurrent logs.
-Also also handle high volume reads and writes per second from thousands of clients.
-
-#### Durable and Consistent
-
-Messages are persisted on disk and replicated to store multiple copies to prevent data loss.
-They are guaranteed to be consistent among writers and readers in terms of strict ordering.
-
-#### Efficient Fan-in and Fan-out
-
-DL provides an efficient serving layer that optimized for running in a multi-tenant datacenter
-environment such as Mesos or Yarn. The serving layer is able to support large scale writes fan-in
-and reads fan-out.
-
-#### Various Workloads
-
-DL supports various workloads from latency sensitive online transaction processing (OLTP) applications
-(e.g. WAL for distributed database and in-memory replicated state machines), real-time stream ingestion
-and computing to analytical processing.
-
-#### Multi Tenant
-
-DL is designed for I/O isolation in real-world workloads, to support large scale of number of logs for multi
-tenants.
-
-#### Layered Architecture
-
-DL has a modern layered-architecture design, that separates stateless serving tier from stateful storage tier.
-It allows scaling storage independent of scaling cpu and memory, to support large scale writes fan-in and
-reads fan-out.
http://git-wip-us.apache.org/repos/asf/incubator-distributedlog/blob/1bd00e9a/_images/costmodel.png
----------------------------------------------------------------------
diff --git a/_images/costmodel.png b/_images/costmodel.png
deleted file mode 100644
index d5fa3dd..0000000
Binary files a/_images/costmodel.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/incubator-distributedlog/blob/1bd00e9a/_images/datamodel.png
----------------------------------------------------------------------
diff --git a/_images/datamodel.png b/_images/datamodel.png
deleted file mode 100644
index be80a87..0000000
Binary files a/_images/datamodel.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/incubator-distributedlog/blob/1bd00e9a/_images/datamodel1.png
----------------------------------------------------------------------
diff --git a/_images/datamodel1.png b/_images/datamodel1.png
deleted file mode 100644
index be80a87..0000000
Binary files a/_images/datamodel1.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/incubator-distributedlog/blob/1bd00e9a/_images/distribution.png
----------------------------------------------------------------------
diff --git a/_images/distribution.png b/_images/distribution.png
deleted file mode 100644
index 76385d4..0000000
Binary files a/_images/distribution.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/incubator-distributedlog/blob/1bd00e9a/_images/fencing.png
----------------------------------------------------------------------
diff --git a/_images/fencing.png b/_images/fencing.png
deleted file mode 100644
index d9dc1f0..0000000
Binary files a/_images/fencing.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/incubator-distributedlog/blob/1bd00e9a/_images/globalreplicatedlog.png
----------------------------------------------------------------------
diff --git a/_images/globalreplicatedlog.png b/_images/globalreplicatedlog.png
deleted file mode 100644
index fdbcbf6..0000000
Binary files a/_images/globalreplicatedlog.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/incubator-distributedlog/blob/1bd00e9a/_images/lacprotocol.png
----------------------------------------------------------------------
diff --git a/_images/lacprotocol.png b/_images/lacprotocol.png
deleted file mode 100644
index c72bca6..0000000
Binary files a/_images/lacprotocol.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/incubator-distributedlog/blob/1bd00e9a/_images/logsegments.png
----------------------------------------------------------------------
diff --git a/_images/logsegments.png b/_images/logsegments.png
deleted file mode 100644
index b013633..0000000
Binary files a/_images/logsegments.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/incubator-distributedlog/blob/1bd00e9a/_images/pubsub.png
----------------------------------------------------------------------
diff --git a/_images/pubsub.png b/_images/pubsub.png
deleted file mode 100644
index a4b2230..0000000
Binary files a/_images/pubsub.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/incubator-distributedlog/blob/1bd00e9a/_images/readrequests.png
----------------------------------------------------------------------
diff --git a/_images/readrequests.png b/_images/readrequests.png
deleted file mode 100644
index d5c42f8..0000000
Binary files a/_images/readrequests.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/incubator-distributedlog/blob/1bd00e9a/_images/requestflow.png
----------------------------------------------------------------------
diff --git a/_images/requestflow.png b/_images/requestflow.png
deleted file mode 100644
index 5eff498..0000000
Binary files a/_images/requestflow.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/incubator-distributedlog/blob/1bd00e9a/_images/requestrouting.png
----------------------------------------------------------------------
diff --git a/_images/requestrouting.png b/_images/requestrouting.png
deleted file mode 100644
index 6cf8080..0000000
Binary files a/_images/requestrouting.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/incubator-distributedlog/blob/1bd00e9a/_images/softwarestack.png
----------------------------------------------------------------------
diff --git a/_images/softwarestack.png b/_images/softwarestack.png
deleted file mode 100644
index fc921cf..0000000
Binary files a/_images/softwarestack.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/incubator-distributedlog/blob/1bd00e9a/_images/softwarestack1.png
----------------------------------------------------------------------
diff --git a/_images/softwarestack1.png b/_images/softwarestack1.png
deleted file mode 100644
index fc921cf..0000000
Binary files a/_images/softwarestack1.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/incubator-distributedlog/blob/1bd00e9a/_sources/api/core.txt
----------------------------------------------------------------------
diff --git a/_sources/api/core.txt b/_sources/api/core.txt
deleted file mode 100644
index f2f0a24..0000000
--- a/_sources/api/core.txt
+++ /dev/null
@@ -1,471 +0,0 @@
-Core Library API
-================
-
-The distributedlog core library interacts with namespaces and logs directly.
-It is written in Java.
-
-Namespace API
--------------
-
-A DL namespace is a collection of *log streams*. Applications could *create*
-or *delete* logs under a DL namespace.
-
-Namespace URI
-~~~~~~~~~~~~~
-
-An **URI** is used to locate the *namespace*. The *Namespace URI* is typically
-comprised of *3* components:
-
-* scheme: `distributedlog-<backend>`. The *backend* indicates what backend is used to store the log data.
-* domain name: the domain name that used to talk to the *backend*. In the example as below, the domain name part is *zookeeper server*, which is used to store log metadata in bookkeeper based backend implementation.
-* path: path points to the location that stores logs. In the example as below, it is a zookeeper path that points to the znode that stores all the logs metadata.
-
-::
-
- distributedlog-bk://<zookeeper-server>/path/to/stream
-
-The available backend is only bookkeeper based backend.
-The default `distributedlog` scheme is aliased to `distributedlog-bk`.
-
-Building a Namespace
-~~~~~~~~~~~~~~~~~~~~
-
-Once you have the *namespace uri*, you could build the namespace instance.
-The namespace instance will be used for operating streams under it.
-
-::
-
- // DistributedLog Configuration
- DistributedLogConfiguration conf = new DistributedLogConfiguration();
- // Namespace URI
- URI uri = ...; // create the namespace uri
- // create a builder to build namespace instances
- DistributedLogNamespaceBuilder builder = DistributedLogNamespaceBuilder.newBuilder();
- DistributedLogNamespace namespace = builder
- .conf(conf) // configuration that used by namespace
- .uri(uri) // namespace uri
- .statsLogger(...) // stats logger to log stats
- .featureProvider(...) // feature provider on controlling features
- .build();
-
-Create a Log
-~~~~~~~~~~~~
-
-Creating a log is pretty straight forward by calling `distributedlognamespace#createlog(logname)`.
-it only creates the log under the namespace but doesn't return any handle for operating the log.
-
-::
-
- DistributedLogNamespace namespace = ...; // namespace
- try {
- namespace.createLog("test-log");
- } catch (IOException ioe) {
- // handling the exception on creating a log
- }
-
-Open a Log
-~~~~~~~~~~
-
-A `DistributedLogManager` handle will be returned when opening a log by `#openLog(logName)`. The
-handle could be used for writing data to or reading data from the log. If the log doesn't exist
-and `createStreamIfNotExists` is set to true in the configuration, the log will be created
-automatically when writing first record.
-
-::
-
- DistributedLogConfiguration conf = new DistributedLogConfiguration();
- conf.setCreateStreamIfNotExists(true);
- DistributedLogNamespace namespace = DistributedLogNamespace.newBuilder()
- .conf(conf)
- ...
- .build();
- DistributedLogManager logManager = namespace.openLog("test-log");
- // use the log manager to open writer to write data or open reader to read data
- ...
-
-Sometimes, applications may open a log with different configuration settings. It could be done via
-a overloaded `#openLog` method, as below:
-
-::
-
- DistributedLogConfiguration conf = new DistributedLogConfiguration();
- // set the retention period hours to 24 hours.
- conf.setRetentionPeriodHours(24);
- URI uri = ...;
- DistributedLogNamespace namespace = DistributedLogNamespace.newBuilder()
- .conf(conf)
- .uri(uri)
- ...
- .build();
-
- // Per Log Configuration
- DistributedLogConfigration logConf = new DistributedLogConfiguration();
- // set the retention period hours to 12 hours for a single stream
- logConf.setRetentionPeriodHours(12);
-
- // open the log with overrided settings
- DistributedLogManager logManager = namespace.openLog("test-log",
- Optional.of(logConf),
- Optiona.absent());
-
-Delete a Log
-~~~~~~~~~~~~
-
-`DistributedLogNamespace#deleteLog(logName)` will deletes the log from the namespace. Deleting a log
-will attempt acquiring a lock before deletion. If a log is writing by an active writer, the lock
-would be already acquired by the writer. so the deleting will fail.
-
-::
-
- DistributedLogNamespace namespace = ...;
- try {
- namespace.deleteLog("test-log");
- } catch (IOException ioe) {
- // handle the exceptions
- }
-
-Log Existence
-~~~~~~~~~~~~~
-
-Applications could check whether a log exists in a namespace by calling `DistributedLogNamespace#logExists(logName)`.
-
-::
-
- DistributedLogNamespace namespace = ...;
- if (namespace.logExists("test-log")) {
- // actions when log exists
- } else {
- // actions when log doesn't exist
- }
-
-Get List of Logs
-~~~~~~~~~~~~~~~~
-
-Applications could list the logs under a namespace by calling `DistributedLogNamespace#getLogs()`.
-
-::
-
- DistributedLogNamespace namespace = ...;
- Iterator<String> logs = namespace.getLogs();
- while (logs.hasNext()) {
- String logName = logs.next();
- // ... process the log
- }
-
-Writer API
-----------
-
-There are two ways to write records into a log stream, one is using 'synchronous' `LogWriter`, while the other one is using
-asynchronous `AsyncLogWriter`.
-
-LogWriter
-~~~~~~~~~
-
-The first thing to write data into a log stream is to construct the writer instance. Please note that the distributedlog core library enforce single-writer
-semantic by deploying a zookeeper locking mechanism. If there is only an active writer, the subsequent calls to `#startLogSegmentNonPartitioned()` will
-fail with `OwnershipAcquireFailedException`.
-
-::
-
- DistributedLogNamespace namespace = ....;
- DistributedLogManager dlm = namespace.openLog("test-log");
- LogWriter writer = dlm.startLogSegmentNonPartitioned();
-
-.. _Construct Log Record:
-
-Log records are constructed to represent the data written to a log stream. Each log record is associated with application defined transaction id.
-The transaction id has to be non-decreasing otherwise writing the record will be rejected with `TransactionIdOutOfOrderException`. Application is allowed to
-bypass the transaction id sanity checking by setting `maxIdSanityCheck` to false in configuration. System time and atomic numbers are good candicates used for
-transaction id.
-
-::
-
- long txid = 1L;
- byte[] data = ...;
- LogRecord record = new LogRecord(txid, data);
-
-Application could either add a single record (via `#write(LogRecord)`) or a bunch of records (via `#writeBulk(List<LogRecord>)`) into the log stream.
-
-::
-
- writer.write(record);
- // or
- List<LogRecord> records = Lists.newArrayList();
- records.add(record);
- writer.writeBulk(records);
-
-The write calls return immediately after the records are added into the output buffer of writer. So the data isn't guaranteed to be durable until writer
-explicitly calls `#setReadyToFlush()` and `#flushAndSync()`. Those two calls will first transmit buffered data to backend, wait for transmit acknowledges
-and commit the written data to make them visible to readers.
-
-::
-
- // flush the records
- writer.setReadyToFlush();
- // commit the records to make them visible to readers
- writer.flushAndSync();
-
-The DL log streams are endless streams unless they are sealed. 'endless' means that writers keep writing records to the log streams, readers could keep
-tailing reading from the end of the streams and it never stops. Application could seal a log stream by calling `#markEndOfStream()`.
-
-::
-
- // seal the log stream
- writer.markEndOfStream();
-
-
-The complete example of writing records is showed as below.
-
-::
-
- DistributedLogNamespace namespace = ....;
- DistributedLogManager dlm = namespace.openLog("test-log");
-
- LogWriter writer = dlm.startLogSegmentNonPartitioned();
- for (long txid = 1L; txid <= 100L; txid++) {
- byte[] data = ...;
- LogRecord record = new LogRecord(txid, data);
- writer.write(record);
- }
- // flush the records
- writer.setReadyToFlush();
- // commit the records to make them visible to readers
- writer.flushAndSync();
-
- // seal the log stream
- writer.markEndOfStream();
-
-AsyncLogWriter
-~~~~~~~~~~~~~~
-
-Constructing an asynchronous `AsyncLogWriter` is as simple as synchronous `LogWriter`.
-
-::
-
- DistributedLogNamespace namespace = ....;
- DistributedLogManager dlm = namespace.openLog("test-log");
- AsyncLogWriter writer = dlm.startAsyncLogSegmentNonPartitioned();
-
-All the writes to `AsyncLogWriter` are asynchronous. The futures representing write results are only satisfied when the data are persisted in the stream durably.
-A DLSN (distributedlog sequence number) will be returned for each write, which is used to represent the position (aka offset) of the record in the log stream.
-All the records adding in order are guaranteed to be persisted in order.
-
-.. _Async Write Records:
-
-::
-
- List<Future<DLSN>> addFutures = Lists.newArrayList();
- for (long txid = 1L; txid <= 100L; txid++) {
- byte[] data = ...;
- LogRecord record = new LogRecord(txid, data);
- addFutures.add(writer.write(record));
- }
- List<DLSN> addResults = Await.result(Future.collect(addFutures));
-
-The `AsyncLogWriter` also provides the method to truncate a stream to a given DLSN. This is super helpful for building replicated state machines, who need
-explicit controls on when the data could be deleted.
-
-::
-
- DLSN truncateDLSN = ...;
- Future<DLSN> truncateFuture = writer.truncate(truncateDLSN);
- // wait for truncation result
- Await.result(truncateFuture);
-
-Reader API
-----------
-
-Sequence Numbers
-~~~~~~~~~~~~~~~~
-
-A log record is associated with sequence numbers. First of all, application can assign its own sequence number (called `TransactionID`)
-to the log record while writing it (see `Construct Log Record`_). Secondly, a log record will be assigned with an unique system generated sequence number
-`DLSN` (distributedlog sequence number) when it is written to a log (see `Async Write Records`_). Besides `DLSN` and `TransactionID`,
-a monotonically increasing 64-bits `SequenceId` is assigned to the record at read time, indicating its position within the log.
-
-:Transaction ID: Transaction ID is a positive 64-bits long number that is assigned by the application.
- Transaction ID is very helpful when application wants to organize the records and position the readers using their own sequencing method. A typical
- use case of `Transaction ID` is `DistributedLog Write Proxy`. The write proxy assigns non-decreasing timestamps to log records, which the timestamps
- could be used as `physical time` to implement `TTL` (Time To Live) feature in a strong consistent database.
-:DLSN: DLSN (DistributedLog Sequence Number) is the sequence number generated during written time.
- DLSN is comparable and could be used to figure out the order between records. A DLSN is comprised with 3 components. They are `Log Segment Sequence Number`,
- `Entry Id` and `Slot Id`. The DLSN is usually used for comparison, positioning and truncation.
-:Sequence ID: Sequence ID is introduced to address the drawback of `DLSN`, in favor of answering questions like `how many records written between two DLSNs`.
- Sequence ID is a 64-bits monotonic increasing number starting from zero. The sequence ids are computed during reading, and only accessible by readers.
- That means writers don't know the sequence ids of records at the point they wrote them.
-
-The readers could be positioned to start reading from any positions in the log, by using `DLSN` or `Transaction ID`.
-
-LogReader
-~~~~~~~~~
-
-`LogReader` is a 'synchronous' sequential reader reading records from a log stream starting from a given position. The position could be
-`DLSN` (via `#getInputStream(DLSN)`) or `Transaction ID` (via `#getInputStream(long)`). After the reader is open, it could call either
-`#readNext(boolean)` or `#readBulk(boolean, int)` to read records out of the log stream sequentially. Closing the reader (via `#close()`)
-will release all the resources occupied by this reader instance.
-
-Exceptions could be thrown during reading records due to various issues. Once the exception is thrown, the reader is set to an error state
-and it isn't usable anymore. It is the application's responsibility to handle the exceptions and re-create readers if necessary.
-
-::
-
- DistributedLogManager dlm = ...;
- long nextTxId = ...;
- LogReader reader = dlm.getInputStream(nextTxId);
-
- while (true) { // keep reading & processing records
- LogRecord record;
- try {
- record = reader.readNext(false);
- nextTxId = record.getTransactionId();
- // process the record
- ...
- } catch (IOException ioe) {
- // handle the exception
- ...
- reader = dlm.getInputStream(nextTxId + 1);
- }
- }
-
-Reading records from an endless log stream in `synchronous` way isn't as trivial as in `asynchronous` way. Because it lacks of callback mechanism.
-Instead, `LogReader` introduces a flag `nonBlocking` on controlling the waiting behavior on `synchronous` reads. Blocking (`nonBlocking = false`)
-means the reads will wait for records before returning read calls, while NonBlocking (`nonBlocking = true`) means the reads will only check readahead
-cache and return whatever records available in readahead cache.
-
-The `waiting` period varies in `blocking` mode. If the reader is catching up with writer (there are plenty of records in the log), the read call will
-wait until records are read and returned. If the reader is already caught up with writer (there are no more records in the log at read time), the read
-call will wait for a small period of time (defined in `DistributedLogConfiguration#getReadAheadWaitTime()`) and return whatever records available in
-readahead cache. In other words, if a reader sees no record on blocking reads, it means the reader is `caught-up` with the writer.
-
-See examples below on how to read records using `LogReader`.
-
-::
-
- // Read individual records
-
- LogReader reader = ...;
- // keep reading records in blocking mode until no records available in the log
- LogRecord record = reader.readNext(false);
- while (null != record) {
- // process the record
- ...
- // read next record
- record = reader.readNext(false);
- }
- ...
-
- // reader is caught up with writer, doing non-blocking reads to tail the log
- while (true) {
- record = reader.readNext(true);
- if (null == record) {
- // no record available yet. backoff ?
- ...
- } else {
- // process the new record
- ...
- }
- }
-
-::
-
- // Read records in batch
-
- LogReader reader = ...;
- int N = 10;
-
- // keep reading N records in blocking mode until no records available in the log
- List<LogRecord> records = reader.readBulk(false, N);
- while (!records.isEmpty()) {
- // process the list of records
- ...
- if (records.size() < N) { // no more records available in the log
- break;
- }
- // read next N records
- records = reader.readBulk(false, N);
- }
-
- ...
-
- // reader is caught up with writer, doing non-blocking reads to tail the log
- while (true) {
- records = reader.readBulk(true, N);
- // process the new records
- ...
- }
-
-
-AsyncLogReader
-~~~~~~~~~~~~~~
-
-Similar as `LogReader`, applications could open an `AsyncLogReader` by positioning to different positions, either `DLSN` or `Transaction ID`.
-
-::
-
- DistributedLogManager dlm = ...;
-
- Future<AsyncLogReader> openFuture;
-
- // position the reader to transaction id `999`
- openFuture = dlm.openAsyncLogReader(999L);
-
- // or position the reader to DLSN
- DLSN fromDLSN = ...;
- openFuture = dlm.openAsyncLogReader(fromDLSN);
-
- AsyncLogReader reader = Await.result(openFuture);
-
-Reading records from an `AsyncLogReader` is asynchronously. The future returned by `#readNext()`, `#readBulk(int)` or `#readBulk(int, long, TimeUnit)`
-represents the result of the read operation. The future is only satisfied when there are records available. Application could chain the futures
-to do sequential reads.
-
-Reading records one by one from an `AsyncLogReader`.
-
-::
-
- void readOneRecord(AsyncLogReader reader) {
- reader.readNext().addEventListener(new FutureEventListener<LogRecordWithDLSN>() {
- public void onSuccess(LogRecordWithDLSN record) {
- // process the record
- ...
- // read next
- readOneRecord(reader);
- }
- public void onFailure(Throwable cause) {
- // handle errors and re-create reader
- ...
- reader = ...;
- // read next
- readOneRecord(reader);
- }
- });
- }
-
- AsyncLogReader reader = ...;
- readOneRecord(reader);
-
-Reading records in batches from an `AsyncLogReader`.
-
-::
-
- void readBulk(AsyncLogReader reader, int N) {
- reader.readBulk(N).addEventListener(new FutureEventListener<List<LogRecordWithDLSN>>() {
- public void onSuccess(List<LogRecordWithDLSN> records) {
- // process the records
- ...
- // read next
- readBulk(reader, N);
- }
- public void onFailure(Throwable cause) {
- // handle errors and re-create reader
- ...
- reader = ...;
- // read next
- readBulk(reader, N);
- }
- });
- }
-
- AsyncLogReader reader = ...;
- readBulk(reader, N);
-
http://git-wip-us.apache.org/repos/asf/incubator-distributedlog/blob/1bd00e9a/_sources/api/main.txt
----------------------------------------------------------------------
diff --git a/_sources/api/main.txt b/_sources/api/main.txt
deleted file mode 100644
index 5c80053..0000000
--- a/_sources/api/main.txt
+++ /dev/null
@@ -1,9 +0,0 @@
-API
-===
-
-.. toctree::
- :maxdepth: 1
-
- core
- proxy
- practice
http://git-wip-us.apache.org/repos/asf/incubator-distributedlog/blob/1bd00e9a/_sources/api/practice.txt
----------------------------------------------------------------------
diff --git a/_sources/api/practice.txt b/_sources/api/practice.txt
deleted file mode 100644
index 419151e..0000000
--- a/_sources/api/practice.txt
+++ /dev/null
@@ -1,76 +0,0 @@
-Best Practices
-==============
-
-Write records using Fat Client or Thin Client
----------------------------------------------
-
-`Fat Client` is the writer in distributedlog core library which talks to ZooKeeper and BookKeeper directly,
-while `Thin Client` is the write proxy client which talks to write proxy service.
-
-It is strongly recommended that writing records via `Write Proxy` service rather than using core library directly.
-Because using `Thin Client` has following benefits:
-
-- `Thin Client` is purely thrift RPC based client. It doesn't talk to zookeeper and bookkeeper directly and less complicated.
-- `Write Proxy` manages ownerships of log writers. `Thin Client` doesn't have to deal with ownerships of log writers.
-- `Thin Client` is more upgrade-friendly than `Fat Client`.
-
-The only exception to use distributedlog core library directly is when you application requires:
-
-- Write Ordering. `Write Ordering` means all the writes issued by the writer should be written in a strict order
- in the log. `Write Proxy` service could only guarantee `Read Ordering`. `Read Ordering` means the write proxies will write
- the write requests in their receiving order and gurantee the data seen by all the readers in same order.
-- Ownership Management. If the application already has any kind of ownership management, like `master-slave`, it makes more
- sense that it uses distributedlog core library directly.
-
-How to position reader by time
-------------------------------
-
-Sometimes, application wants to read data by time, like read data from 2 hours ago. This could be done by positioning
-the reader using `Transaction ID`, if the `Transaction ID` is the timestamp (All the streams produced by `Write Proxy` use
-timestamp as `Transaction ID`).
-
-::
-
- DistributedLogManager dlm = ...;
-
- long timestamp = System.currentTimeMillis();
- long startTxId = timestamp - TimeUnit.MILLISECONDS.convert(2, TimeUnit.HOURS);
- AsyncLogReader reader = Await.result(dlm.openAsyncLogReader(startTxId));
- ...
-
-How to seal a stream
---------------------
-
-Typically, DistributedLog is used as endless streams. In some use cases, application wants to `seal` the stream. So writers
-can't write more data into the log stream and readers could receive notifications about the stream has been sealed.
-
-Write could seal a log stream as below:
-
-::
-
- DistributedLogManager dlm = ...;
-
- LogWriter writer = dlm.startLogSegmentNonPartitioned;
- // writer writes bunch of records
- ...
-
- // writer seals the stream
- writer.markEndOfStream();
-
-Reader could detect a stream has been sealed as below:
-
-::
-
- DistributedLogManager dlm = ...;
-
- LogReader reader = dlm.getInputStream(1L);
- LogRecord record;
- try {
- while ((record = reader.readNext(false)) != null) {
- // process the record
- ...
- }
- } catch (EndOfStreamException eos) {
- // the stream has been sealed
- ...
- }
http://git-wip-us.apache.org/repos/asf/incubator-distributedlog/blob/1bd00e9a/_sources/api/proxy.txt
----------------------------------------------------------------------
diff --git a/_sources/api/proxy.txt b/_sources/api/proxy.txt
deleted file mode 100644
index ad2b56b..0000000
--- a/_sources/api/proxy.txt
+++ /dev/null
@@ -1,74 +0,0 @@
-Write Proxy Client API
-======================
-
-`Write Proxy` is a 'stateless' service on managing the ownerships of writers of log streams. It is used to
-accept to `fan-in` writes from different publishers.
-
-Build Client
-------------
-
-The first thing of using `Write Proxy` service is to build the write proxy client. The endpoint of a `Write Proxy` service
-is typically identified by `Finagle Name`_. Name strings must be supplied when constructing a `Write Proxy` client.
-
-.. _Finagle Name: http://twitter.github.io/finagle/guide/Names.html
-
-::
-
- // 1. Create a Finagle client builder. It would be used for building connection to write proxies.
- ClientBuilder clientBuilder = ClientBuilder.get()
- .hostConnectionLimit(1)
- .hostConnectionCoresize(1)
- .tcpConnectTimeout(Duration$.MODULE$.fromMilliseconds(200))
- .connectTimeout(Duration$.MODULE$.fromMilliseconds(200))
- .requestTimeout(Duration$.MODULE$.fromSeconds(2));
-
- // 2. Choose a client id to identify the client.
- ClientId clientId = ClientId$.MODULE$.apply("test");
-
- String finagleNameStr = "inet!127.0.0.1:8000";
-
- // 3. Create the write proxy client builder
- DistributedLogClientBuilder builder = DistributedLogClientBuilder.newBuilder()
- .name("test-writer")
- .clientId(clientId)
- .clientBuilder(clientBuilder)
- .statsReceiver(statsReceiver)
- .finagleNameStr(finagleNameStr);
-
- // 4. Build the client
- DistributedLogClient client = builder.build();
-
-Write Records
--------------
-
-Writing records to log streams via `Write Proxy` is much simpler than using the core library. The transaction id
-will be automatically assigned with `timestamp` by write proxies. The `timestamp` is guaranteed to be non-decreasing, which it
-could be treated as `physical time` within a log stream, and be used for implementing features like `TTL` in a strong consistent
-database.
-
-::
-
- DistributedLogClient client = ...;
-
- // Write a record to a stream
- String streamName = "test-stream";
- byte[] data = ...;
- Future<DLSN> writeFuture = client.write(streamName, ByteBuffer.wrap(data));
- Await.result(writeFuture);
-
-Truncate Streams
-----------------
-
-Client could issue truncation requests (via `#truncate(String, DLSN)`) to write proxies to truncate a log stream up to a given
-position.
-
-::
-
- DistributedLogClient client = ...;
-
- // Truncate a stream to DLSN
- String streamName = "test-stream";
- DLSN truncationDLSN = ...;
- Future<DLSN> truncateFuture = client.truncate(streamName, truncationDLSN);
- Await.result(truncateFuture);
-
http://git-wip-us.apache.org/repos/asf/incubator-distributedlog/blob/1bd00e9a/_sources/architecture/main.txt
----------------------------------------------------------------------
diff --git a/_sources/architecture/main.txt b/_sources/architecture/main.txt
deleted file mode 100644
index e66cdcb..0000000
--- a/_sources/architecture/main.txt
+++ /dev/null
@@ -1,160 +0,0 @@
-Architecture
-============
-
-Data Model
-----------
-
-DistributedLog exposes the `log stream` as the unit of operations. A `log stream` is a totally ordered,
-immutable sequence of log records. A `log record` is a sequence of bytes. Log records are batched into `entries`
-and written into `log segments`. Figure 1 illustrates the logical elements of a log stream.
-
-.. figure:: ../images/datamodel.png
- :align: center
-
- Figure 1. Anatomy of a log stream
-
-Log Segments
-~~~~~~~~~~~~
-
-Although the application views the log stream as a continuous sequence of log records, it is physically stored as
-multiple `log segments`, where these segments are the unit of `manageability`. All the records in a log segment have
-the same replication configuration. The log segments are allocated, distributed and stored in a `log segment store`.
-As records are written to the log stream, DistributedLog switches to a new log segment based on a configured `rolling policy`.
-The rolling policy can be `time-based` i.e. based on a configured period of time (e.g. every 2 hours) or `size-based`
-i.e. based on a maximum log segment size (e.g. every 128MB). This allows the log segments to be distributed evenly
-across all the storage nodes. This helps evenly spread read traffic to avoid hot spots in the cluster.
-
-A log segment is also the unit of data retention. Log segments are deleted either by explicitly truncation or expiration.
-Old data is garbage collected by the log segment store once the log segments are deleted.
-
-Log Sequence Numbers
-~~~~~~~~~~~~~~~~~~~~
-
-`Log records` are written sequentially into a log stream, and assigned a unique sequence number called `DLSN`
-(DistributedLog Sequence Number). A DLSN is comprised of 3 components: a `Log Segment Sequence Number` (LSSN),
-the sequence number of the log segment that the record belongs to, an `Entry ID` (EID) - the entry id in this log segment
-that the record is in, and a `Slot ID` (SID) - the slot within the entry. Records can be ordered by DLSN.
-
-Besides DLSN, an application can assign a `Transaction ID`, a non-decreasing positive 64-bit integer, to each log record it writes.
-This facilitates application-specific sequencing of records and positioning of the reader. For example, a common use of the transaction ID
-is to store the timestamp of when the log record was added to the log stream. This transaction ID can then be used to rewind to a specific
-time in analytics applications.
-
-Namespace
-~~~~~~~~~
-
-Log streams that belong to same application are usually categorized and managed under a `namespace`. A `namespace` is used by applications
-to locate where the log streams are. Applications can `create` and `delete` streams under a namespace, and `truncate` a stream to given ID.
-
-Software Stack
---------------
-
-The software stack is shown in Figure 2. The software stack is divided into three layers, with each layer is responsible for
-different features of DistributedLog. These layers are `Persistent Storage`, `DistributedLog Core` and `Stateless Serving`.
-
-.. figure:: ../images/softwarestack.png
- :align: center
-
- Figure 2. DistributedLog Software Stack
-
-Persistent Storage
-~~~~~~~~~~~~~~~~~~
-
-DistributedLog provides the core features - `durability`, `availability` and `consistency` through the storage layer.
-The main components in storage layer are `Log Segment Store`, `Cold Storage` and `Metadata Store`.
-
-Log Segment Store
-+++++++++++++++++
-
-The Log segment store is responsible for storing the log segments as they are created and ensure they are durably replicated.
-We use `Apache BookKeeper` as the log segment store. BookKeeper helps us achieve low tail latencies for writes and reads as well as
-low delivery latency which is the end to end latency from when the record is generated until it is read by the reader - because bookkeeper's
-storage layout is optimized for I/O isolation for log workloads.
-
-In addition to storage layout optimization, the log segment store (via BookKeeper) also provides a built-in `fencing` mechanism for
-achieving strong consistency among multiple writers. We will discuss more about consistency in section `Design Details`.
-
-Cold Storage
-++++++++++++
-
-The data in the log segment store is eventually moved to a `cold storage`. Cold storage allows cost efficient storage of large volumes
-of log segments for extended period of time. Applications many want to have access to old data for application error recovery or debugging.
-As log segments are completed, they are proactively copied over to the cold storage, thereby providing a backup for disaster recovery or an
-operation error. We use HDFS as our cold storage.
-
-Metadata Store
-++++++++++++++
-
-The metadata in DistributedLog consists of the mapping from log streams to their constituent log segments as well as each log segment\u2019s metadata.
-The log segment metadata includes the `log segment ID`, `start and end transaction IDs`, `completion time`, and its `status`. The metadata store
-is required to provide metadata operations such as consistent read and write ordering to guarantee metadata consistency in the event of failures.
-Also the metadata store should provide a notification mechanism to support streaming reads. We use ZooKeeper as the metadata store, because it is
-a strongly consistent data store which provides versioned updates, strong ordering and notifications using watches.
-
-DistributedLog Core
-~~~~~~~~~~~~~~~~~~~
-
-DistributedLog builds its core functionality on top of the log segment store and the metadata store. It provides the core data model of log streams
-and its naming system, and provides a `single-writer-multiple-reader` access model.
-
-Writers write data into the logs of their choice. Writers sequence log records written to the log streams. Therefore there is only one active log
-segment for a given log stream at a time. Correctness and consistency are guaranteed using a fencing mechanism in the log segment store and
-versioned metadata updates to prevent two writers from writing to the same log stream after a network partition.
-
-Reading from a log stream starts by `positioning` a reader on a log record by specifying either a DLSN or a Transaction Id. Once a reader has been
-positioned, it receives all the log records in increasing order of the sequence numbers and each record is delivered exactly once. It is up to
-individual applications to choose an appropriate mechanism to record readers positions and provide this position when a new reader session begins
-(e.g restart from a failure). Applications can choose the appropriate method for storing positions based on the desired processing semantics.
-
-Stateless Serving
-~~~~~~~~~~~~~~~~~
-
-A stateless serving layer is built on top of the storage layer to support large number of writers and readers. The serving layer includes `Write Proxy`
-and `Read Proxy`. `Write Proxy` manages the ownerships of the log streams, forwards the write requests to storage via the core library and handles
-load balancing and failover. It allows sequencing writes from many clients (aka `Fan-in`). `Read Proxy` caches log records for multiple readers consuming
-the same log stream.
-
-Ownership Tracker
-+++++++++++++++++
-
-`Ownership Tracker` tracks the liveness of the owners of the log streams and fails over the ownership to other healthy write proxies when the current
-owner becomes unavailable. Since we already use zookeeper for metadata storage, we also use zookeeper for tracking the liveness of write proxies using
-`ephemeral znodes` and failover the ownership when zookeeper session expires.
-
-Routing Service
-+++++++++++++++
-Since readers read committed data and are strict followers, the read proxies do not have to track ownership of log streams. We use consistent hashing
-as a routing mechanism to route the readers to corresponding read proxies.
-
-Applications can either use a thin client that talks to the serving tier to access DistributedLog or embed the core library to talk to the storage directly
-when they require strict write ordering. Applications choose partitioning strategies and track their reader positions based on their specific requirements.
-
-Lifecyle of records
--------------------
-
-Figure 3 illustrates the lifecycle of a log record in DistributedLog as it flows from writers to readers and we discuss how different layers interact with
-each other.
-
-.. figure:: ../images/requestflow.png
- :align: center
-
- Figure 3. Lifecycle of a record
-
-The application constructs the log records and initiates write requests (step 1). The write requests will be forwarded to the write proxy that is the master
-of the log stream. The master writer proxy will write the records in the log stream\u2019s transmit buffer. Based on the configured transmit policy, records in
-the transmit buffer will be transmitted as a batched entry to log segment store (step 2). Application can trade latency for throughput by transmitting
-`immediately` (lowest latency), `periodically` (grouping records that appear within the transmit period) or when transmit buffer has accumulated more than
-`max-outstanding bytes`.
-
-The batched entry is transmitted to multiple bookies (storage nodes in bookkeeper cluster) in parallel (step 3). The log segment store will respond back to
-writer once the entry is persisted durably on disk. Once the write proxy receives confirmation of durability from a quorum of bookies, it will send an
-acknowledgement to the application (step 4).
-
-Although the writer knows that the record is guaranteed to be persisted and replicated in bookkeeper. Individual bookies do not necessarily know that the
-consensus agreement has been reached for this record. The writer must therefore record a `commit` to make this record visible to all the readers.
-This `commit` can piggyback on the next batch of records from the application. If no new application records are received within the specified SLA for
-persistence, the writer will issue a special `control log record` notifying the log segment store that the record can now be made visible to readers (step 5).
-
-The readers\u2019 request that is waiting for new data using `long polling` will now receive the recent committed log records (step 6). Speculative long poll reads will be sent to other replicas to archieve predictable low 99.9% percentile latency (step 7).
-
-The log records will be cached in read proxies (step 8) for fanout readers. The read clients also use similar long poll read mechanism to read data from read proxies (step 9).
http://git-wip-us.apache.org/repos/asf/incubator-distributedlog/blob/1bd00e9a/_sources/basics/introduction.txt
----------------------------------------------------------------------
diff --git a/_sources/basics/introduction.txt b/_sources/basics/introduction.txt
deleted file mode 100644
index e29bb28..0000000
--- a/_sources/basics/introduction.txt
+++ /dev/null
@@ -1,120 +0,0 @@
-Introduction
-============
-
-DistributedLog (DL) is a high performance replicated log service.
-It offers durability, replication and strong consistency, which provides a fundamental building block
-for building reliable distributed systems, e.g replicated-state-machines, general pub/sub systems,
-distributed databases, distributed queues and etc.
-
-DistributedLog maintains sequences of records in categories called *Logs* (aka *Log Streams*).
-The processes that write records to a DL log are *writers*, while the processes that read
-from logs and process the records are *readers*.
-
-
-.. figure:: ../images/softwarestack.png
- :align: center
-
- Figure 1. DistributedLog Software Stack
-
-Logs
-----
-
-A **log** is an ordered, immutable sequence of *log records*.
-
-.. figure:: ../images/datamodel.png
- :align: center
-
- Figure 2. Anatomy of a log stream
-
-Log Records
-~~~~~~~~~~~
-
-Each **log record** is a sequence of bytes.
-**Log records** are written sequentially into a *log stream*, and will be assigned with
-a unique sequence number *called* **DLSN** (DistributedLog Sequence Number). Besides *DLSN*,
-applications could assign its own sequence number while constructing log records. The
-application defined sequence number is called **TransactionID** (*txid*). Either *DLSN*
-or *TransactionID* could be used for positioning readers to start reading from a specific
-*log record*.
-
-Log Segments
-~~~~~~~~~~~~
-
-A **log** is broken down into *segments*, which each log segment contains its subset of
-records. **Log segments** are distributed and stored in a log segment store (e.g Apache BookKeeper).
-DistributedLog rolls the log segments based on configured rolling policy - either a configurable
-period of time (e.g. every 2 hours) or a configurable maximum size (e.g. every 128MB).
-So the data of logs will be divided into equal-sized *log segments* and distributed evenly
-across log segment storage nodes. It allows the log to scale beyond a size that will fit on
-a single server and also spread read traffic among the cluster.
-
-The data of logs will either be kept forever until application *explicitly* truncates or be retained
-for a configurable period of time. **Explicit Truncation** is useful for building replicated
-state machines such as distributed databases. They usually require strong controls over when
-the data could be truncated. **Time-based Retention** is useful for real-time analytics. They only
-care about the data within a period of time.
-
-Namespaces
-~~~~~~~~~~
-
-The *log streams* belong to same organization are usually categorized and managed under
-a **namespace**. A DL **namespace** is basically for applications to locate where the
-*log streams* are. Applications could *create* and *delete* streams under a namespace,
-and also be able to *truncate* a stream to given sequence number (either *DLSN* or *TransactionID*).
-
-Writers
--------
-
-Writers write data into the logs of their choice. All the records are
-appended into the logs in order. The sequencing is done by the writer,
-which means there is only one active writer for a log at a given time.
-DL guarantees correctness when two writers attempt writing to
-to a same log when network partition happens - via fencing mechanism
-in log segment store.
-
-The log writers are served and managed in a service tier called *Write Proxy*.
-The *Write Proxy* is used for accepting fan-in writes from large number
-of clients. Details on **Fan-in and Fan-out** can be found further into this doc.
-
-Readers
--------
-
-Readers read records from the logs of their choice, starting from a provided
-position. The provided position could be either *DLSN* or *TransactionID*.
-The readers will read records in strict order from the logs. Different readers
-could read records starting from different positions in a same log.
-
-Unlike other pub/sub systems, DistributedLog doesn't record/manage readers' positions.
-It leaves the tracking responsibility to applications, as different applications
-might have different requirements on tracking and coordinating positions. It is hard
-to get it right with a single approach. For example, distributed databases might store
-the reader positions along with SSTables, so they would resume applying transactions
-from the positions stored in SSTables. Tracking reader positions could easily be done
-in application level using various stores (e.g. ZooKeeper, FileSystem, or Key/Value Stores).
-
-The log records could be cached in a service tier called *Read Proxy*, to serve
-large number of readers. Details on **Fan-in and Fan-out** can be found further into this doc.
-
-Fan-in and Fan-out
-------------------
-
-The core of DistributedLog supports single-writer, multiple-readers semantics. The service layer
-built on top of the *DistributedLog Core* to support large scale of number of writers and readers.
-The service layer includes **Write Proxy** and **Read Proxy**. **Write Proxy** manages
-the writers of logs and fail over them when machines are failed. It allows supporting
-which don't care about the log ownership by aggregating writes from many sources (aka *Fan-in*).
-**Read Proxy** optimize reader path by caching log records in cases where hundreds or
-thousands of readers are consuming a same log stream.
-
-Guarantees
-----------
-
-At a high-level, DistributedLog gives the following guarantees:
-
-* Records written by a writer to a log will be appended in the order they are written. That is, if a record *R1* is written by same writer as a record *R2*, *R1* will have a smaller sequence number than *R2*.
-* Readers will see records in same order they were written to the log.
-* All records were persisted on disks before acknowledges, to gurantee durability.
-* For a log with replication factor of N, DistributedLog tolerates up to N-1 server failures without losing any records appended to the log.
-
-More details on these guarantees are given in the design section of this documentation.
-
http://git-wip-us.apache.org/repos/asf/incubator-distributedlog/blob/1bd00e9a/_sources/basics/main.txt
----------------------------------------------------------------------
diff --git a/_sources/basics/main.txt b/_sources/basics/main.txt
deleted file mode 100644
index 06d0afd..0000000
--- a/_sources/basics/main.txt
+++ /dev/null
@@ -1,8 +0,0 @@
-Getting Started
-===============
-
-.. toctree::
- :maxdepth: 1
-
- introduction
- quickstart
http://git-wip-us.apache.org/repos/asf/incubator-distributedlog/blob/1bd00e9a/_sources/basics/quickstart.txt
----------------------------------------------------------------------
diff --git a/_sources/basics/quickstart.txt b/_sources/basics/quickstart.txt
deleted file mode 100644
index 7053628..0000000
--- a/_sources/basics/quickstart.txt
+++ /dev/null
@@ -1,106 +0,0 @@
-Quick Start
-===========
-
-This tutorial assumes you are starting from fresh and have no existing BookKeeper or ZooKeeper data.
-
-Step 1: Download the binary
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-:doc:`Download <../download>` the stable version of `DistributedLog` and un-zip it.
-
-::
-
- // Download the binary `distributedlog-all-${gitsha}.zip`
- > unzip distributedlog-all-${gitsha}.zip
-
-
-Step 2: Start ZooKeeper & BookKeeper
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-DistributedLog uses `ZooKeeper` as the metadata store and `BookKeeper` as the log segment store. So
-you need to first start a zookeeper server and a few bookies if you don't already have one. You can
-use the `dlog` script in `distributedlog-service` package to get a standalone bookkeeper sandbox. It
-starts a zookeeper server and `N` bookies (N is 3 by default).
-
-::
-
- // Start the local sandbox instance at port `7000`
- > ./distributedlog-service/bin/dlog local 7000
- DistributedLog Sandbox is running now. You could access distributedlog://127.0.0.1:7000
-
-
-Step 3: Create a DistributedLog namespace
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Before using distributedlog, you need to create a distributedlog namespace to store your own list of
-streams. The zkServer for the local sandbox is `127.0.0.1:7000` and the bookkeeper's ledgers path is
-`/ledgers`. You could create a namespace pointing to the corresponding bookkeeper cluster.
-
-::
-
- > ./distributedlog-service/bin/dlog admin bind -l /ledgers -s 127.0.0.1:7000 -c distributedlog://127.0.0.1:7000/messaging/my_namespace
- No bookkeeper is bound to distributedlog://127.0.0.1:7000/messaging/my_namespace
- Created binding on distributedlog://127.0.0.1:7000/messaging/my_namespace.
-
-
-If you don't want to create a separated namespace, you could use the default namespace `distributedlog://127.0.0.1:7000/messaging/distributedlog`.
-
-
-Step 4: Create some log streams
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Let's create 5 log streams, prefixed with `messaging-test-`.
-
-::
-
- > ./distributedlog-service/bin/dlog tool create -u distributedlog://127.0.0.1:7000/messaging/my_namespace -r messaging-stream- -e 1-5
-
-
-We can now see the streams if we run the `list` command from the tool.
-
-::
-
- > ./distributedlog-service/bin/dlog tool list -u distributedlog://127.0.0.1:7000/messaging/my_namespace
- Streams under distributedlog://127.0.0.1:7000/messaging/my_namespace :
- --------------------------------
- messaging-stream-1
- messaging-stream-3
- messaging-stream-2
- messaging-stream-4
- messaging-stream-5
- --------------------------------
-
-
-Step 5: Start a write proxy
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Now, lets start a write proxy server that serves writes to distributedlog namespace `distributedlog://127.0.0.1/messaging/my_namespace`. The server listens on 8000 to accept fan-in write requests.
-
-::
-
- > ./distributedlog-service/bin/dlog-daemon.sh start writeproxy -p 8000 --shard-id 1 -sp 8001 -u distributedlog://127.0.0.1:7000/messaging/my_namespace -mx -c `pwd`/distributedlog-service/conf/distributedlog_proxy.conf
-
-
-Step 6: Tail reading records
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The distributedlog tutorial has a multi-streams reader that will dump out received records to standard output.
-
-::
-
- > ./distributedlog-tutorials/distributedlog-basic/bin/runner run com.twitter.distributedlog.basic.MultiReader distributedlog://127.0.0.1:7000/messaging/my_namespace messaging-stream-1,messaging-stream-2,messaging-stream-3,messaging-stream-4,messaging-stream-5
-
-
-Step 7: Write some records
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The distributedlog tutorial also has a multi-streams writer that will take input from a console and write it out
-as records to the distributedlog write proxy. Each line will be sent as a separate record.
-
-Run the writer and type a few lines into the console to send to the server.
-
-::
-
- > ./distributedlog-tutorials/distributedlog-basic/bin/runner run com.twitter.distributedlog.basic.ConsoleProxyMultiWriter 'inet!127.0.0.1:8000' messaging-stream-1,messaging-stream-2,messaging-stream-3,messaging-stream-4,messaging-stream-5
-
-If you have each of the above commands running in a different terminal then you should now be able to type messages into the writer terminal and see them appear in the reader terminal.
http://git-wip-us.apache.org/repos/asf/incubator-distributedlog/blob/1bd00e9a/_sources/basics/usecases.txt
----------------------------------------------------------------------
diff --git a/_sources/basics/usecases.txt b/_sources/basics/usecases.txt
deleted file mode 100644
index f74b17a..0000000
--- a/_sources/basics/usecases.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-Use Cases
-=========
-
-Here is a description of a few popular use cases for DistributedLog.
-
-Messaging
----------
-
-(add description on messaging or pub/sub)
-
-Replicated State Machines
--------------------------
-
-(add description on replicated state machines like database journal)
-
-Reliable XDC Replication
-------------------------
-
-(add description on reliable xdc replication)