Github user hmcl commented on a diff in the pull request: https://github.com/apache/storm/pull/2537#discussion_r165851895 --- Diff: external/storm-kafka-client/src/main/java/org/apache/storm/kafka/spout/KafkaSpoutConfig.java --- @@ -143,28 +146,28 @@ public String toString() { /** * This enum controls when the tuple with the {@link ConsumerRecord} for an offset is marked as processed, - * i.e. when the offset can be committed to Kafka. + * i.e. when the offset can be committed to Kafka. The default value is AT_LEAST_ONCE. * The commit interval is controlled by {@link KafkaSpoutConfig#getOffsetsCommitPeriodMs() }, if the mode commits on an interval. * NO_GUARANTEE may be removed in a later release without warning, we're still evaluating whether it makes sense to keep. - * - * <ul> - * <li>AT_LEAST_ONCE - an offset is ready to commit only after the corresponding tuple has been processed and acked (at least once). If - * a tuple fails or times out it will be re-emitted, as controlled by the {@link KafkaSpoutRetryService}. Commits on the defined - * interval.</li> - * <br/> - * <li>AT_MOST_ONCE - every offset will be committed to Kafka right after being polled but before being emitted to the downstream - * components of the topology. The commit interval is ignored. This mode guarantees that the offset is processed at most once by - * ensuring the spout won't retry tuples that fail or time out after the commit to Kafka has been done.</li> - * <br/> - * <li>NO_GUARANTEE - the polled offsets are ready to commit immediately after being polled. The offsets are committed periodically, - * i.e. a message may be processed 0, 1 or more times. This behavior is similar to setting enable.auto.commit=true in the consumer, but - * allows the spout to control when commits occur. Commits on the defined interval. </li> - * </ul> */ @InterfaceStability.Unstable public enum ProcessingGuarantee { + /** + * An offset is ready to commit only after the corresponding tuple has been processed and acked (at least once). If a tuple fails or + * times out it will be re-emitted, as controlled by the {@link KafkaSpoutRetryService}. Commits on the defined interval. + */ AT_LEAST_ONCE, + /** + * Every offset will be committed to Kafka right after being polled but before being emitted to the downstream components of the + * topology. The commit interval is ignored. This mode guarantees that the offset is processed at most once by ensuring the spout + * won't retry tuples that fail or time out after the commit to Kafka has been done + */ AT_MOST_ONCE, + /** + * The polled offsets are ready to commit immediately after being polled. The offsets are committed periodically, i.e. a message may + * be processed 0, 1 or more times. This behavior is similar to setting enable.auto.commit=true in the consumer, but allows the + * spout to control when commits occur. Commits on the defined interval --- End diff -- Commits are made asynchronously on the defined interval. Should we also say specifically that for A_L_O and A_M_O the commits are done synchronously ?
---