Github user hmcl commented on the issue:
    @srdo @jfenc91 I am on vacation this week (with limited access to Internet) 
and I will be back on Monday. **Can we please holding on merging this until I 
can finish my review on Monday**. I implemented the original patch, and would 
like to review these changes.Thanks.
    I am still a bit confused about the duplicated acking tuples. If that is 
the case, that could be a possible storm guarantees problem, which should be 
fixed at its root cause, and not worked around in spout code. Furthermore, from 
what I understand, as far as the findNextOffset method behavior, the duplicate 
acking should be irrelevant, because once all the tuples up to a certain offset 
have been acked, they will be committed in the next commit call. For example 
let's say `1,2,3,4,5, 8,9,10` have acked, on the next commit call, `1,2,3,4,5` 
should be committed, but `8,9,10` won't be until `6,7` get acked. If `6,7` 
never get acked, say (retry forever scenario), then the desired behavior is 
that `8,9,10` never get committed. @jfenc91 Can you help me understand how does 
the duplicate acking interfere in this scenario, and how?

If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at or file a JIRA ticket
with INFRA.

Reply via email to