[
https://issues.apache.org/jira/browse/STORM-876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15025295#comment-15025295
]
ASF GitHub Bot commented on STORM-876:
--------------------------------------
Github user knusbaum commented on a diff in the pull request:
https://github.com/apache/storm/pull/845#discussion_r45790060
--- Diff:
storm-core/src/jvm/backtype/storm/blobstore/KeySequenceNumber.java ---
@@ -0,0 +1,227 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package backtype.storm.blobstore;
+
+import backtype.storm.nimbus.NimbusInfo;
+import backtype.storm.utils.Utils;
+import org.apache.curator.framework.CuratorFramework;
+import org.apache.zookeeper.CreateMode;
+import org.apache.zookeeper.ZooDefs;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+import java.nio.ByteBuffer;
+import java.util.TreeSet;
+import java.util.Map;
+import java.util.List;
+
+/**
+ * Class hands over the key sequence number which implies the number of
updates made to a blob.
+ * The information regarding the keys and the sequence number which
represents the number of updates are
+ * stored within the zookeeper in the following format.
+ * /storm/blobstore/key_name/nimbushostport-sequencenumber
+ * Example:
+ * If there are two nimbodes with nimbus.seeds:leader,non-leader are set,
+ * then the state inside the zookeeper is eventually stored as:
+ * /storm/blobstore/key1/leader:8080-1
+ * /storm/blobstore/key1/non-leader:8080-1
+ * indicates that a new blob with the name key1 has been created on the
leader
+ * nimbus and the non-leader nimbus syncs after a call back is triggered
by attempting
+ * to download the blob and finally updates its state inside the zookeeper.
+ *
+ * A watch is placed on the /storm/blobstore/key1 and the znodes
leader:8080-1 and
+ * non-leader:8080-1 are ephemeral which implies that these nodes exist
only until the
+ * connection between the corresponding nimbus and the zookeeper persist.
If in case the
+ * nimbus crashes the node disappears under /storm/blobstore/key1.
+ *
+ * The sequence number for the keys are handed over based on the following
scenario:
+ * Lets assume there are three nimbodes up and running, one being the
leader and the other
+ * being the non-leader.
+ *
+ * 1. Create is straight forward.
+ * Check whether the znode -> /storm/blobstore/key1 has been created or
not. It implies
+ * the blob has not been created yet. If not created, it creates it and
updates the zookeeper
+ * states under /storm/blobstore/key1 and
/storm/blobstoremaxkeysequencenumber/key1.
+ * The znodes it creates on these nodes are
/storm/blobstore/key1/leader:8080-1,
+ * /storm/blobstore/key1/non-leader:8080-1 and
/storm/blobstoremaxkeysequencenumber/key1/1.
+ * The later holds the global sequence number across all nimbodes more
like a static variable
+ * indicating the true value of number of updates for a blob. This node
helps to maintain sanity in case
+ * leadership changes due to crashing.
+ *
+ * 2. Delete does not require to hand over the sequence number.
+ *
+ * 3. Finally, the update has few scenarios.
+ *
+ * The class implements a TreeSet. The basic idea is if all the nimbodes
have the same
+ * sequence number for the blob, then the number of elements in the set
is 1 which holds
+ * the latest value of sequence number. If the number of elements are
greater than 1 then it
+ * implies that there is sequence mismatch and there is need for syncing
the blobs across
+ * nimbodes.
+ *
+ * The logic for handing over sequence numbers based on the state are
described as follows
+ * Here consider Nimbus-1 alias as N1 and Nimbus-2 alias as N2.
+ * Scenario 1:
+ * Example: Normal create/update scenario
+ * Operation Nimbus-1:state Nimbus-2:state Seq-Num-Nimbus-1
Seq-Num-Nimbus-2 Max-Seq-Num
+ * Create-Key1 alive - Leader alive 1
1
+ * Sync alive - Leader alive 1
1 (callback -> download) 1
+ * Update-Key1 alive - Leader alive 2
1 2
+ * Sync alive - Leader alive 2
2 (callback -> download) 2
+ *
+ * Scenario 2:
+ * Example: Leader nimbus crash followed by leader election, update and
ex-leader restored again
+ * Operation Nimbus-1:state Nimbus-2:state Seq-Num-Nimbus-1
Seq-Num-Nimbus-2 Max-Seq-Num
+ * Create alive - Leader alive 1
1
+ * Sync alive - Leader alive 1
1 (callback -> download) 1
+ * Update alive - Leader alive 2
1 2
+ * Sync alive - Leader alive 2
2 (callback -> download) 2
+ * Update alive - Leader alive 3
2 3
+ * Crash crash - Leader alive 3
2 3
+ * New - Leader crash alive - Leader 3 (Invalid)
2 3
+ * Update crash alive - Leader 3 (Invalid)
4 (max-seq-num + 1) 4
+ * N1-Restored alive alive - Leader 0
4 4
+ * Sync alive alive - Leader 4
4 4
+ *
+ * Scenario 3:
+ * Example: Leader nimbus crash followed by leader election, update and
ex-leader restored again
+ * Operation Nimbus-1:state Nimbus-2:state Seq-Num-Nimbus-1
Seq-Num-Nimbus-2 Max-Seq-Num
+ * Create alive - Leader alive 1
1
+ * Sync alive - Leader alive 1
1 (callback -> download) 1
+ * Update alive - Leader alive 2
1 2
+ * Sync alive - Leader alive 2
2 (callback -> download) 2
+ * Update alive - Leader alive 3
2 3
+ * Crash crash - Leader alive 3
2 3
+ * Elect Leader crash alive - Leader 3 (Invalid)
2 3
+ * N1-Restored alive alive - Leader 3
2 3
+ * Read/Update alive alive - Leader 3
4 (Downloads from N1) 4
+ * Sync alive alive - Leader 4 (callback)
4 4
+ * Here the download is triggered whenever an operation corresponding to
the blob is triggered on the
+ * nimbus like a read or update operation. Here, in the read/update call
it is hard to know which call
+ * is read or update. Hence, by incrementing the sequence number to
max-seq-num + 1 we ensure that the
+ * synchronization happens appropriately and all nimbodes have the same
blob.
+ */
--- End diff --
Yeah, +1000 on the documentation.
> Dist Cache: Basic Functionality
> -------------------------------
>
> Key: STORM-876
> URL: https://issues.apache.org/jira/browse/STORM-876
> Project: Apache Storm
> Issue Type: Improvement
> Components: storm-core
> Reporter: Robert Joseph Evans
> Assignee: Robert Joseph Evans
> Attachments: DISTCACHE.md, DistributedCacheDesignDocument.pdf
>
>
> Basic functionality for the Dist Cache feature.
> As part of this a new API should be added to support uploading and
> downloading dist cache items. storm-core.ser, storm-conf.ser and storm.jar
> should be written into the blob store instead of residing locally. We need a
> default implementation of the blob store that does essentially what nimbus
> currently does and does not need anything extra. But having an HDFS backend
> too would be great for scalability and HA.
> The supervisor should provide a way to download and manage these blobs and
> provide a working directory for the worker process with symlinks to the
> blobs. It should also allow the blobs to be updated and switch the symlink
> atomically to point to the new blob once it is downloaded.
> All of this is already done by code internal to Yahoo! we are in the process
> of getting it ready to push back to open source shortly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
