storm-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [04/50] [abbrv] storm git commit: STORM-166: reformatting some sections.
Date Mon, 24 Aug 2015 13:51:49 GMT
STORM-166: reformatting some sections.


Branch: refs/heads/master
Commit: e05d6663a3dbc056e9f21194f83fe0e27509f83e
Parents: 07b69b7
Author: Parth Brahmbhatt <>
Authored: Fri Dec 19 13:01:27 2014 -0800
Committer: Parth Brahmbhatt <>
Committed: Fri Dec 19 13:01:27 2014 -0800

 docs/documentation/ | 13 ++++++-------
 1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/docs/documentation/ b/docs/documentation/
index 51b15f8..cb6332f 100644
--- a/docs/documentation/
+++ b/docs/documentation/
@@ -13,9 +13,8 @@ of the backups will take over.
 the list of potential leaders automatically. 
 * No topology resubmissions required in case of nimbus fail overs.
 * No active topology should ever be lost. 
-Following are different components to achieve the above goals.
-###Leader Election:
+##Leader Election:
 The nimbus server will use the following interface:
@@ -81,7 +80,7 @@ This sequence diagram describes how leader election and failover would work
 ![Nimbus Fail Over](images/nimbus_ha_leader_election_and_failover.png)
-###Nimbus state store:
+##Nimbus state store:
 Currently the nimbus stores 2 kind of data
 * Meta information like supervisor info, assignment info which is stored in zookeeper
@@ -93,9 +92,9 @@ and it is hard to test for correctness.However many storm users do not want
to t
 storage system like HDFS and still need high availability.Eventually, we want to move to
the bittorrent protocol for code 
 distribution given the size of the jars and to achieve better scaling when the total number
of supervisors is very high. 
 The current file system based model for code distribution works fine with systems that have
file system like structure
-but it fails to support a non file system based approach like bit torrent. To support bit
torrent we can go with the 
-following interface instead of the storage interface described above. The interface described
below can still be used with
-HDFS,S3 and local file system, so this is a more extensible interface. 
+but it fails to support a non file system based approach like bit torrent. To support bit
torrent and all the file
+system based replicated storage systems we propose the following interface:
  * Interface responsible to distribute code in the cluster.

View raw message