[
https://issues.apache.org/jira/browse/GEARPUMP-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16220294#comment-16220294
]
ASF GitHub Bot commented on GEARPUMP-359:
-----------------------------------------
Github user manuzhang commented on a diff in the pull request:
https://github.com/apache/incubator-gearpump/pull/234#discussion_r147105502
--- Diff:
streaming/src/main/scala/org/apache/gearpump/streaming/task/Subscription.scala
---
@@ -209,7 +202,8 @@ class Subscription(
// to throttle the number of unacked AckRequest
incrementMessageCount(partition, ackOnceEveryMessageCount)
val targetTask = TaskId(processorId, partition)
- val ackRequest = AckRequest(taskId, messageCount(partition), sessionId)
+ val processingWaterMark = publisher.getProcessingWatermark.toEpochMilli
--- End diff --
nitpick: processingWaterMark => processingWatermark
> The premature OutputWatermark advancing logic in Subscription is not right
> --------------------------------------------------------------------------
>
> Key: GEARPUMP-359
> URL: https://issues.apache.org/jira/browse/GEARPUMP-359
> Project: Apache Gearpump
> Issue Type: Bug
> Reporter: Huafeng Wang
> Assignee: Huafeng Wang
>
> {{Subscription}} will update processingWatermark when sending a message and
> update outputWatermark when receiving an Ack message. It will cause
> prematurely updating the outputWatermark in such scenario: the
> {{Subscription}} already sent 200 messages to downstream and now the
> processingWatermark is 200th message's watermark, then it receives the first
> 100 messages' Ack and it will advance the outputWatermark to 200th message's
> watermark, not the 100th one, which is wrong.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
