Modified: samza/site/learn/documentation/latest/jobs/configuration-table.html URL: http://svn.apache.org/viewvc/samza/site/learn/documentation/latest/jobs/configuration-table.html?rev=1740179&r1=1740178&r2=1740179&view=diff ============================================================================== --- samza/site/learn/documentation/latest/jobs/configuration-table.html (original) +++ samza/site/learn/documentation/latest/jobs/configuration-table.html Wed Apr 20 18:14:27 2016 @@ -184,6 +184,27 @@ </tr> <tr> + <td class="property" id="job-coordinator-monitor-partition-change">job.coordinator.<br />monitor-partition-change</td> + <td class="default">false</td> + <td class="description"> + If you are using Kafka for coordinator stream, this configuration enables the Job Coordinator to + detect partition count difference in Kafka input topics. On detection, it updates a Gauge + metric of format <span class="system">system-name</span>.<span class="stream">stream-name</span>.partitionCount, + which indicates the difference in the partition count from the initial state. Please note that currently this + feature only works for Kafka-based systems. + </td> + </tr> + + <tr> + <td class="property" id="job-coordinator-monitor-partition-change-frequency-ms">job.coordinator.<br />monitor-partition-change.frequency.ms</td> + <td class="default">300000</td> + <td class="description"> + The frequency at which the input streams' partition count change should be detected. This check + can be tuned to be pretty low as partition increase is not a common event. + </td> + </tr> + + <tr> <td class="property" id="job-config-rewriter-class">job.config.rewriter.<br><span class="rewriter">rewriter-name</span>.class</td> <td class="default"></td> <td class="description"> @@ -231,6 +252,13 @@ </dl> </td> </tr> + <tr> + <td class="property" id="job-checkpoint-validation-enabled">job.checkpoint.<br>validation.enabled</td> + <td class="default">true</td> + <td class="description"> + This setting controls if the job should fail(true) or just warn(false) in case the validation of checkpoint partition number fails. <br/> <b>CAUTION</b>: this configuration needs to be used w/ care. It should only be used as a work-around after the checkpoint has been auto-created with wrong number of partitions by mistake. + </td> + </tr> <tr> <th colspan="3" class="section" id="task"><a href="../api/overview.html">Task configuration</a></th> @@ -1518,10 +1546,15 @@ <td class="description">A date format (using Java's SimpleDataFormat syntax) appropriate for use in an HDFS Path, which can configure time-based bucketing of output files.</td> </tr> <tr> - <td class="property" id="hdfs-write-batch-size-bytes">systems.*.producer.write.batch.size.bytes</td> + <td class="property" id="hdfs-write-batch-size-bytes">systems.*.producer.hdfs.write.batch.size.bytes</td> <td class="default">268435456</td> <td class="description">The number of bytes of outgoing messages to write to each HDFS output file before cutting a new file. Defaults to 256MB if not set.</td> </tr> + <tr> + <td class="property" id="hdfs-write-batch-size-records">systems.*.producer.hdfs.write.batch.size.records</td> + <td class="default">262144</td> + <td class="description">The number of outgoing messages to write to each HDFS output file before cutting a new file. Defaults to 262144 if not set.</td> + </tr> <tr> <th colspan="3" class="section" id="task-migration">
Modified: samza/site/learn/documentation/latest/jobs/logging.html URL: http://svn.apache.org/viewvc/samza/site/learn/documentation/latest/jobs/logging.html?rev=1740179&r1=1740178&r2=1740179&view=diff ============================================================================== --- samza/site/learn/documentation/latest/jobs/logging.html (original) +++ samza/site/learn/documentation/latest/jobs/logging.html Wed Apr 20 18:14:27 2016 @@ -176,13 +176,14 @@ <div class="highlight"><pre><code class="bash">-Dsamza.container.name<span class="o">=</span>samza-application-master</code></pre></div> -<p>These settings are very useful if you’re using a file-based appender. For example, you can use a daily rolling appender by configuring log4j.xml like this:</p> +<p>These settings are very useful if you’re using a file-based appender. For example, you can use a rolling appender to separate log file when it reaches certain size by configuring log4j.xml like this:</p> -<div class="highlight"><pre><code class="xml"><span class="nt"><appender</span> <span class="na">name=</span><span class="s">"RollingAppender"</span> <span class="na">class=</span><span class="s">"org.apache.log4j.DailyRollingFileAppender"</span><span class="nt">></span> +<div class="highlight"><pre><code class="xml"><span class="nt"><appender</span> <span class="na">name=</span><span class="s">"RollingAppender"</span> <span class="na">class=</span><span class="s">"org.apache.log4j.RollingFileAppender"</span><span class="nt">></span> <span class="nt"><param</span> <span class="na">name=</span><span class="s">"File"</span> <span class="na">value=</span><span class="s">"${samza.log.dir}/${samza.container.name}.log"</span> <span class="nt">/></span> - <span class="nt"><param</span> <span class="na">name=</span><span class="s">"DatePattern"</span> <span class="na">value=</span><span class="s">"'.'yyyy-MM-dd"</span> <span class="nt">/></span> + <span class="nt"><param</span> <span class="na">name=</span><span class="s">"MaxFileSize"</span> <span class="na">value=</span><span class="s">"256MB"</span> <span class="nt">/></span> + <span class="nt"><param</span> <span class="na">name=</span><span class="s">"MaxBackupIndex"</span> <span class="na">value=</span><span class="s">"20"</span> <span class="nt">/></span> <span class="nt"><layout</span> <span class="na">class=</span><span class="s">"org.apache.log4j.PatternLayout"</span><span class="nt">></span> - <span class="nt"><param</span> <span class="na">name=</span><span class="s">"ConversionPattern"</span> <span class="na">value=</span><span class="s">"%d{yyyy-MM-dd HH:mm:ss} %c{1} [%p] %m%n"</span> <span class="nt">/></span> + <span class="nt"><param</span> <span class="na">name=</span><span class="s">"ConversionPattern"</span> <span class="na">value=</span><span class="s">"%d{yyyy-MM-dd HH:mm:ss.SSS} [%t] %c{1} [%p] %m%n"</span> <span class="nt">/></span> <span class="nt"></layout></span> <span class="nt"></appender></span></code></pre></div> @@ -211,7 +212,7 @@ <span class="c"><!-- optional --></span> <span class="nt"><param</span> <span class="na">name=</span><span class="s">"StreamName"</span> <span class="na">value=</span><span class="s">"EpicStreamName"</span><span class="nt">/></span> <span class="nt"><layout</span> <span class="na">class=</span><span class="s">"org.apache.log4j.PatternLayout"</span><span class="nt">></span> - <span class="nt"><param</span> <span class="na">name=</span><span class="s">"ConversionPattern"</span> <span class="na">value=</span><span class="s">"%X{containerName} %X{jobName} %X{jobId} %d{yyyy-MM-dd HH:mm:ss} %c{1} [%p] %m%n"</span> <span class="nt">/></span> + <span class="nt"><param</span> <span class="na">name=</span><span class="s">"ConversionPattern"</span> <span class="na">value=</span><span class="s">"%X{containerName} %X{jobName} %X{jobId} %d{yyyy-MM-dd HH:mm:ss.SSS} [%t] %c{1} [%p] %m%n"</span> <span class="nt">/></span> <span class="nt"></layout></span> <span class="nt"></appender></span></code></pre></div> Modified: samza/site/learn/documentation/latest/yarn/yarn-host-affinity.html URL: http://svn.apache.org/viewvc/samza/site/learn/documentation/latest/yarn/yarn-host-affinity.html?rev=1740179&r1=1740178&r2=1740179&view=diff ============================================================================== --- samza/site/learn/documentation/latest/yarn/yarn-host-affinity.html (original) +++ samza/site/learn/documentation/latest/yarn/yarn-host-affinity.html Wed Apr 20 18:14:27 2016 @@ -145,7 +145,7 @@ <p>In Samza, containers are the units of physical parallelism that runs on a set of machines. Each container is essentially a process that runs one or more stream tasks. Each task instance consumes one or more partitions of the input streams and is associated with its own durable data store. </p> -<p>We define a <em>Stateful Samza Job</em> as the Samza job that uses a key-value store in its implementation, alone with an associated changelog stream. In stateful samza jobs, there is a 1:1 mapping between the task instance and the data store. Since the allocation of containers to machines in the Yarn cluster is completely left to Yarn, Samza does not guarantee that a container (and hence, its associated task(s)) gets deployed on the same machine. Containers can get shuffled in any of the following cases:</p> +<p>We define a <em>Stateful Samza Job</em> as the Samza job that uses a key-value store in its implementation, along with an associated changelog stream. In stateful samza jobs, a task may be configured to use multiple stores. For each store there is a 1:1 mapping between the task instance and the data store. Since the allocation of containers to machines in the Yarn cluster is completely left to Yarn, Samza does not guarantee that a container (and hence, its associated task(s)) gets deployed on the same machine. Containers can get shuffled in any of the following cases:</p> <ol> <li>When a job is upgraded by pointing <code>yarn.package.path</code> to the new package path and re-submitted.</li> @@ -155,7 +155,7 @@ <p>In any of the above cases, the task’s co-located data needs to be restored every time a container starts-up. Restoring data each time can be expensive, especially for applications that have a large data set. This behavior slows the start-up time for the job so much that the job is no longer “near realtime”. Furthermore, if multiple stateful samza jobs restart around the same time in the cluster and they all share the same changelog system, then it is possible to quickly saturate the changelog system’s network and cause a DDoS.</p> -<p>For instance, consider a Samza job performing a Stream-Table join. Typically, such a job requires the dataset to be available on all processors before they begin processing the input stream. The dataset is usually large (order > 1TB) read-only data that will be used to join or add attributes to incoming messages. The job may initialize this cache by populated with data directly from a remote store or changelog stream. This cache initialization happens each time the container is restarted. This causes significant latency during job start-up.</p> +<p>For instance, consider a Samza job performing a Stream-Table join. Typically, such a job requires the dataset to be available on all processors before they begin processing the input stream. The dataset is usually large (order > 1TB) read-only data that will be used to join or add attributes to incoming messages. The job may initialize this cache by populating it with data directly from a remote store or changelog stream. This cache initialization happens each time the container is restarted. This causes significant latency during job start-up.</p> <p>The solution, then, is to simply persist the state store on the machine in which the container process is executing and re-allocate the same host for the container each time the job is restarted, in order to re-use the persisted state. Thus, the ability of Samza to allocate a container to the same machine across job restarts is referred to as <strong><em>host-affinity</em></strong>. Samza leverages host-affinity to enhance our support for local state re-use.</p> @@ -172,20 +172,19 @@ ls <span class="k">${</span><span class= <p><img src="/img/latest/learn/documentation/yarn/samza-host-affinity.png" alt="samza-host-affinity"></p> -<p>When a container is <em>cleanly shutdown</em>, Samza also writes the last materialized offset from the changelog stream to the checksumed file on disk. Thus, there is an <em>OFFSET</em> file associated with each state stores' changelog partitions, that is consumed by the tasks in the container.</p> +<p>Each time a task commits, Samza writes the last materialized offset from the changelog stream to the checksumed file on disk. This is also done on container shutdown. Thus, there is an <em>OFFSET</em> file associated with each state stores' changelog partitions, that is consumed by the tasks in the container.</p> <div class="highlight"><pre><code class="bash"><span class="k">${</span><span class="nv">LOGGED_STORE_BASE_DIR</span><span class="k">}</span>/<span class="k">${</span><span class="nv">job</span><span class="p">.name</span><span class="k">}</span>-<span class="k">${</span><span class="nv">job</span><span class="p">.id</span><span class="k">}</span>/<span class="k">${</span><span class="nv">store</span><span class="p">.name</span><span class="k">}</span>/<span class="k">${</span><span class="nv">task</span><span class="p">.name</span><span class="k">}</span>/OFFSET</code></pre></div> -<p>Now, when a container restarts on the same machine after a clean shutdown and the OFFSET file exists, the Samza container:</p> +<p>Now, when a container restarts on the same machine after the OFFSET file exists, the Samza container:</p> <ol> <li>Opens the persisted store on disk</li> <li>Reads the OFFSET file</li> -<li>Deletes the OFFSET file</li> <li>Restores the state store from the OFFSET value</li> </ol> -<p>If the OFFSET file doesn’t exist, it creates the state store and consumes from the oldest offset in the changelog to re-create the state. Note that Samza optimistically deletes the OFFSET file in step 3 to prevent data from getting corrupted due to any kind of failure during state restoration. This significantly reduces the state restoration time on container start-up as we no longer consume from the beginning of the changelog stream.</p> +<p>This significantly reduces the state restoration time on container start-up as we no longer consume from the beginning of the changelog stream. If the OFFSET file doesn’t exist, it creates the state store and consumes from the oldest offset in the changelog to re-create the state. Since the OFFSET file is written on each commit after flushing the store, the recorded offset is guaranteed to correspond to the current contents of the store or some older point, but never newer. This gives at least once semantics for state restore. Therefore, the changelog entries must be idempotent.</p> <p>It is necessary to periodically clean-up unused or orphaned state stores on the machines to manage disk-space. This feature is being worked on in <a href="https://issues.apache.org/jira/browse/SAMZA-656";>SAMZA-656</a>.</p> @@ -226,6 +225,7 @@ Without this configuration, the state st <span class="nt"><description></span>No. of ms to wait between sending a SIGTERM and SIGKILL to a container<span class="nt"></description></span> <span class="nt"><value></span>600000<span class="nt"></value></span> <span class="c"><!-- Set it to 10min to allow enough time for clean shutdown of containers --></span> <span class="nt"></property></span></code></pre></div></p></li> +<li><p>The Yarn <a href="https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-common/RackAwareness.html";>Rack Awareness</a> feature is not required and does not change the behavior of Samza Host Affinity. However, if Rack Awareness is configured in the cluster, make sure the DNSToSwitchMapping implementation is robust. Any failures could cause container requests to fall back to the defaultRack. This will cause ContainerRequests to not match the preferred host, which will degrade Host Affinity. For details, see <a href="https://issues.apache.org/jira/browse/SAMZA-886";>SAMZA-866</a></p></li> </ol> <h2 id="configuring-a-samza-job-to-use-host-affinity">Configuring a Samza job to use Host Affinity</h2> @@ -241,7 +241,7 @@ Without this configuration, the state st <p>As you have observed, host-affinity cannot be guaranteed all the time due to varibale load distribution in the Yarn cluster. Hence, this is a best-effort policy that Samza provides. However, certain scenarios are worth calling out where these guarantees may be hard to achieve or are not applicable.</p> <ol> -<li><em>When the number of containers and/or container-task assignment changes across successive application runs</em> - We may be able to re-use local state for a subset of partitions. Currently, there is no logic in the Job Coordinator to handle partitioning of tasks among containers intelligently. Handling this is more involved as relates to <a href="https://issues.apache.org/jira/browse/SAMZA-336";>auto-scaling</a> of the containers.</li> +<li><em>When the number of containers and/or container-task assignment changes across successive application runs</em> - We may be able to re-use local state for a subset of partitions. Currently, there is no logic in the Job Coordinator to handle partitioning of tasks among containers intelligently. Handling this is more involved as relates to <a href="https://issues.apache.org/jira/browse/SAMZA-336";>auto-scaling</a> of the containers. However, with <a href="https://issues.apache.org/jira/browse/SAMZA-906";>task-container mapping</a>, this will work better for typical container count adjustments.</li> <li><em>When SystemStreamPartitionGrouper changes across successive application runs</em> - When the grouper logic used to distribute the partitions across containers changes, the data in the Coordinator Stream (for changelog-task partition assignment etc) and the data stores becomes invalid. Thus, to be safe, we should flush out all state-related data from the Coordinator Stream. An alternative is to overwrite the Task-ChangelogPartition assignment message and the Container Locality message in the Coordinator Stream, before starting up the job again.</li> </ol> Modified: samza/site/sitemap.xml URL: http://svn.apache.org/viewvc/samza/site/sitemap.xml?rev=1740179&r1=1740178&r2=1740179&view=diff ============================================================================== --- samza/site/sitemap.xml (original) +++ samza/site/sitemap.xml Wed Apr 20 18:14:27 2016 @@ -20,7 +20,7 @@ <url> <loc>http://samza.apache.org/</loc> - <lastmod>2016-02-11</lastmod> + <lastmod>2016-04-20</lastmod> <changefreq>daily</changefreq> <priority>1.0</priority> </url> @@ -30,357 +30,357 @@ <url> <loc>http://samza.apache.org/learn/documentation/versioned/yarn/application-master.html</loc> - <lastmod>2016-02-11</lastmod> + <lastmod>2016-04-20</lastmod> </url> <url> <loc>http://samza.apache.org/learn/documentation/versioned/introduction/architecture.html</loc> - <lastmod>2016-02-11</lastmod> + <lastmod>2016-04-20</lastmod> </url> <url> <loc>http://samza.apache.org/learn/documentation/versioned/introduction/background.html</loc> - <lastmod>2016-02-11</lastmod> + <lastmod>2016-04-20</lastmod> </url> <url> <loc>http://samza.apache.org/learn/documentation/versioned/container/checkpointing.html</loc> - <lastmod>2016-02-11</lastmod> + <lastmod>2016-04-20</lastmod> </url> <url> <loc>http://samza.apache.org/contribute/code.html</loc> - <lastmod>2016-02-11</lastmod> + <lastmod>2016-04-20</lastmod> </url> <url> <loc>http://samza.apache.org/contribute/coding-guide.html</loc> - <lastmod>2016-02-11</lastmod> + <lastmod>2016-04-20</lastmod> </url> <url> <loc>http://samza.apache.org/community/committers.html</loc> - <lastmod>2016-02-11</lastmod> + <lastmod>2016-04-20</lastmod> </url> <url> <loc>http://samza.apache.org/learn/documentation/versioned/introduction/concepts.html</loc> - <lastmod>2016-02-11</lastmod> + <lastmod>2016-04-20</lastmod> </url> <url> <loc>http://samza.apache.org/learn/documentation/versioned/jobs/configuration.html</loc> - <lastmod>2016-02-11</lastmod> + <lastmod>2016-04-20</lastmod> </url> <url> <loc>http://samza.apache.org/learn/documentation/versioned/container/coordinator-stream.html</loc> - <lastmod>2016-02-11</lastmod> + <lastmod>2016-04-20</lastmod> </url> <url> <loc>http://samza.apache.org/learn/tutorials/versioned/deploy-samza-job-from-hdfs.html</loc> - <lastmod>2016-02-11</lastmod> + <lastmod>2016-04-20</lastmod> </url> <url> <loc>http://samza.apache.org/learn/tutorials/versioned/deploy-samza-to-CDH.html</loc> - <lastmod>2016-02-11</lastmod> + <lastmod>2016-04-20</lastmod> </url> <url> <loc>http://samza.apache.org/contribute/design-documents.html</loc> - <lastmod>2016-02-11</lastmod> + <lastmod>2016-04-20</lastmod> </url> <url> <loc>http://samza.apache.org/learn/documentation/versioned/container/event-loop.html</loc> - <lastmod>2016-02-11</lastmod> + <lastmod>2016-04-20</lastmod> </url> <url> <loc>http://samza.apache.org/learn/documentation/versioned/index.html</loc> - <lastmod>2016-02-11</lastmod> + <lastmod>2016-04-20</lastmod> </url> <url> <loc>http://samza.apache.org/archive/index.html</loc> - <lastmod>2016-02-11</lastmod> + <lastmod>2016-04-20</lastmod> </url> <url> <loc>http://samza.apache.org/learn/tutorials/versioned/index.html</loc> - <lastmod>2016-02-11</lastmod> + <lastmod>2016-04-20</lastmod> </url> <url> <loc>http://samza.apache.org/index.html</loc> - <lastmod>2016-02-11</lastmod> + <lastmod>2016-04-20</lastmod> </url> <url> <loc>http://samza.apache.org/startup/download/index.html</loc> - <lastmod>2016-02-11</lastmod> + <lastmod>2016-04-20</lastmod> </url> <url> <loc>http://samza.apache.org/startup/hello-samza/versioned/index.html</loc> - <lastmod>2016-02-11</lastmod> + <lastmod>2016-04-20</lastmod> </url> <url> <loc>http://samza.apache.org/learn/documentation/versioned/comparisons/introduction.html</loc> - <lastmod>2016-02-11</lastmod> + <lastmod>2016-04-20</lastmod> </url> <url> <loc>http://samza.apache.org/community/irc.html</loc> - <lastmod>2016-02-11</lastmod> + <lastmod>2016-04-20</lastmod> </url> <url> <loc>http://samza.apache.org/learn/documentation/versioned/yarn/isolation.html</loc> - <lastmod>2016-02-11</lastmod> + <lastmod>2016-04-20</lastmod> </url> <url> <loc>http://samza.apache.org/learn/documentation/versioned/container/jmx.html</loc> - <lastmod>2016-02-11</lastmod> + <lastmod>2016-04-20</lastmod> </url> <url> <loc>http://samza.apache.org/learn/documentation/versioned/jobs/job-runner.html</loc> - <lastmod>2016-02-11</lastmod> + <lastmod>2016-04-20</lastmod> </url> <url> <loc>http://samza.apache.org/learn/documentation/versioned/operations/kafka.html</loc> - <lastmod>2016-02-11</lastmod> + <lastmod>2016-04-20</lastmod> </url> <url> <loc>http://samza.apache.org/learn/documentation/versioned/jobs/logging.html</loc> - <lastmod>2016-02-11</lastmod> + <lastmod>2016-04-20</lastmod> </url> <url> <loc>http://samza.apache.org/community/mailing-lists.html</loc> - <lastmod>2016-02-11</lastmod> + <lastmod>2016-04-20</lastmod> </url> <url> <loc>http://samza.apache.org/learn/documentation/versioned/container/metrics.html</loc> - <lastmod>2016-02-11</lastmod> + <lastmod>2016-04-20</lastmod> </url> <url> <loc>http://samza.apache.org/learn/documentation/versioned/comparisons/mupd8.html</loc> - <lastmod>2016-02-11</lastmod> + <lastmod>2016-04-20</lastmod> </url> <url> <loc>http://samza.apache.org/learn/documentation/versioned/api/overview.html</loc> - <lastmod>2016-02-11</lastmod> + <lastmod>2016-04-20</lastmod> </url> <url> <loc>http://samza.apache.org/learn/documentation/versioned/jobs/packaging.html</loc> - <lastmod>2016-02-11</lastmod> + <lastmod>2016-04-20</lastmod> </url> <url> <loc>http://samza.apache.org/learn/documentation/versioned/hdfs/producer.html</loc> - <lastmod>2016-02-11</lastmod> + <lastmod>2016-04-20</lastmod> </url> <url> <loc>http://samza.apache.org/contribute/projects.html</loc> - <lastmod>2016-02-11</lastmod> + <lastmod>2016-04-20</lastmod> </url> <url> <loc>http://samza.apache.org/learn/tutorials/versioned/remote-debugging-samza.html</loc> - <lastmod>2016-02-11</lastmod> + <lastmod>2016-04-20</lastmod> </url> <url> <loc>http://samza.apache.org/learn/documentation/versioned/jobs/reprocessing.html</loc> - <lastmod>2016-02-11</lastmod> + <lastmod>2016-04-20</lastmod> </url> <url> <loc>http://samza.apache.org/contribute/rules.html</loc> - <lastmod>2016-02-11</lastmod> + <lastmod>2016-04-20</lastmod> </url> <url> <loc>http://samza.apache.org/learn/tutorials/versioned/run-hello-samza-without-internet.html</loc> - <lastmod>2016-02-11</lastmod> + <lastmod>2016-04-20</lastmod> </url> <url> <loc>http://samza.apache.org/learn/tutorials/versioned/run-in-multi-node-yarn.html</loc> - <lastmod>2016-02-11</lastmod> + <lastmod>2016-04-20</lastmod> </url> <url> <loc>http://samza.apache.org/learn/documentation/versioned/container/samza-container.html</loc> - <lastmod>2016-02-11</lastmod> + <lastmod>2016-04-20</lastmod> </url> <url> <loc>http://samza.apache.org/learn/documentation/versioned/operations/security.html</loc> - <lastmod>2016-02-11</lastmod> + <lastmod>2016-04-20</lastmod> </url> <url> <loc>http://samza.apache.org/learn/documentation/versioned/container/serialization.html</loc> - <lastmod>2016-02-11</lastmod> + <lastmod>2016-04-20</lastmod> </url> <url> <loc>http://samza.apache.org/learn/documentation/versioned/comparisons/spark-streaming.html</loc> - <lastmod>2016-02-11</lastmod> + <lastmod>2016-04-20</lastmod> </url> <url> <loc>http://samza.apache.org/learn/documentation/versioned/container/state-management.html</loc> - <lastmod>2016-02-11</lastmod> + <lastmod>2016-04-20</lastmod> </url> <url> <loc>http://samza.apache.org/learn/documentation/versioned/comparisons/storm.html</loc> - <lastmod>2016-02-11</lastmod> + <lastmod>2016-04-20</lastmod> </url> <url> <loc>http://samza.apache.org/learn/documentation/versioned/container/streams.html</loc> - <lastmod>2016-02-11</lastmod> + <lastmod>2016-04-20</lastmod> </url> <url> <loc>http://samza.apache.org/contribute/tests.html</loc> - <lastmod>2016-02-11</lastmod> + <lastmod>2016-04-20</lastmod> </url> <url> <loc>http://samza.apache.org/learn/documentation/versioned/jobs/web-ui-rest-api.html</loc> - <lastmod>2016-02-11</lastmod> + <lastmod>2016-04-20</lastmod> </url> <url> <loc>http://samza.apache.org/learn/documentation/versioned/container/windowing.html</loc> - <lastmod>2016-02-11</lastmod> + <lastmod>2016-04-20</lastmod> </url> <url> <loc>http://samza.apache.org/learn/documentation/versioned/yarn/yarn-host-affinity.html</loc> - <lastmod>2016-02-11</lastmod> + <lastmod>2016-04-20</lastmod> </url> <url> <loc>http://samza.apache.org/learn/documentation/versioned/jobs/yarn-jobs.html</loc> - <lastmod>2016-02-11</lastmod> + <lastmod>2016-04-20</lastmod> </url>
