Github user arunmahadevan commented on a diff in the pull request:
https://github.com/apache/storm/pull/2090#discussion_r113383001
--- Diff:
storm-client/src/jvm/org/apache/storm/windowing/TimeTriggerPolicy.java ---
@@ -62,7 +63,9 @@ public void reset() {
@Override
public void start() {
- executorFuture = executor.scheduleAtFixedRate(newTriggerTask(),
duration, duration, TimeUnit.MILLISECONDS);
+ // initial delay is slightly less than the duration so that the
initial tuples wont't expire due to time drift
+ long initialDelay = duration - Math.min((long) (duration * .1),
100);
+ executorFuture = executor.scheduleAtFixedRate(newTriggerTask(),
initialDelay, duration, TimeUnit.MILLISECONDS);
--- End diff --
We cant't guarantee the absolute time at which the trigger will fire since
it depends on when and how long storm takes to initialize the bolt. Only the
relative time difference between two window firings can be guaranteed. The
issue was that the first trigger was firing a few milliseconds after the
duration which was causing the initial tuples to directly expire. I have
refactored the logic to not depend on the initial delay being slightly lesser.
---
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 [email protected] or file a JIRA ticket
with INFRA.
---
