[
https://issues.apache.org/jira/browse/METRON-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16613672#comment-16613672
]
ASF GitHub Bot commented on METRON-1778:
----------------------------------------
GitHub user nickwallen opened a pull request:
https://github.com/apache/metron/pull/1197
METRON-1778 Out-of-order timestamps may delay flush in Storm Profiler
In the Storm Profiler, when timestamps are received out-of-order there can
be cases where a flush signal can be either delayed or occur prematurely. The
smaller the profile period is, the more likely this is to impact the results.
This is more likely to impact things like integration tests that run with small
profile period values. I would not expect this to greatly impact the results
of the Profiler under normal usage.
## Changes
The previous implementation of `FixedFrequencyFlushSignal` set the flush
time based only on the first timestamp it sees. With out-of-order timestamps
the flush time can effectively change as additional data arrives.
* See `FixedFrequencyFlushSignalTest.testOutOfOrderTimestamps` for an
example of how this logic can cause a problem
* The fix in this PR tracks the min and max timestamps that have been seen.
If max > min + flushFrequency, then it is time to flush. Otherwise, it is not
time to flush.
* I added a fair number of unit tests and described in the comments what
should happen.
## Testing
There is not an easy way to manually test this as it requires a very
specific sequence of timestamps to trigger. I feel the updates that were made
to the unit tests, along with regression testing the environment as described
in the Profiler README, is sufficient.
## Pull Request Checklist
- [ ] Is there a JIRA ticket associated with this PR? If not one needs to
be created at [Metron
Jira](https://issues.apache.org/jira/browse/METRON/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel).
- [ ] Does your PR title start with METRON-XXXX where XXXX is the JIRA
number you are trying to resolve? Pay particular attention to the hyphen "-"
character.
- [ ] Has your PR been rebased against the latest commit within the target
branch (typically master)?
- [ ] Have you included steps to reproduce the behavior or problem that is
being changed or addressed?
- [ ] Have you included steps or a guide to how the change may be verified
and tested manually?
- [ ] Have you ensured that the full suite of tests and checks have been
executed in the root metron folder via:
- [ ] Have you written or updated unit tests and or integration tests to
verify your changes?
- [ ] If adding new dependencies to the code, are these dependencies
licensed in a way that is compatible for inclusion under [ASF
2.0](http://www.apache.org/legal/resolved.html#category-a)?
- [ ] Have you verified the basic functionality of the build by building
and running locally with Vagrant full-dev environment or the equivalent?
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/nickwallen/metron METRON-1778
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/metron/pull/1197.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #1197
----
commit afa7e7cde4cf2335b5491c7e39a46bb03f4eb643
Author: Nick Allen <nick@...>
Date: 2018-09-13T14:20:06Z
METRON-1778 Out-of-order timestamps may delay flush in Spark Profiler
commit 0e708b07a9e2f061d92717463618908532d476f7
Author: Nick Allen <nick@...>
Date: 2018-09-13T15:39:54Z
Added back check for out-of-order timestamps
----
> Out-of-order timestamps may delay flush in Storm Profiler
> ---------------------------------------------------------
>
> Key: METRON-1778
> URL: https://issues.apache.org/jira/browse/METRON-1778
> Project: Metron
> Issue Type: Bug
> Reporter: Nick Allen
> Assignee: Nick Allen
> Priority: Major
>
> When timestamps are received out-of-order there can be cases where a flush
> signal should have been signalled, but is not. The flush signal can be
> either delayed slightly or occur prematurely.
> The smaller the profile period is, the more likely this is to impact the
> results. I would not expect this to greatly impact the results of the
> Profiler under normal usage.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
