Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

NIFI-3332: ListXXX to not miss files with the latest processed timestamp #1975

Closed
wants to merge 3 commits into from
Closed

NIFI-3332: ListXXX to not miss files with the latest processed timestamp #1975

wants to merge 3 commits into from

Conversation

ijokarumawak
Copy link
Member

Thank you for submitting a contribution to Apache NiFi.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

For all changes:

  • Is there a JIRA ticket associated with this PR? Is it referenced
    in the commit message?

  • Does your PR title start with NIFI-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)?

  • Is your initial contribution a single, squashed commit?

For code changes:

  • Have you ensured that the full suite of tests is executed via mvn -Pcontrib-check clean install at the root nifi folder?
  • Have you written or updated unit 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?
  • If applicable, have you updated the LICENSE file, including the main LICENSE file under nifi-assembly?
  • If applicable, have you updated the NOTICE file, including the main NOTICE file found under nifi-assembly?
  • If adding new Properties, have you added .displayName in addition to .name (programmatic access) for each of the new properties?

For documentation related changes:

  • Have you ensured that format looks appropriate for the output in which it is rendered?

Note:

Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible.

@ijokarumawak
Copy link
Member Author

As #1915 changes the same files and these two are related, I created this PR based on #1915.

@bbende
Copy link
Contributor

bbende commented Aug 25, 2017

@ijokarumawak was reviewing this, running a full build rebased against master i am consistently getting this test failure:

java.lang.IndexOutOfBoundsException: Index: 0, Size: 0

at java.util.ArrayList.rangeCheck(ArrayList.java:653)
at java.util.ArrayList.get(ArrayList.java:429)
at org.apache.nifi.processors.standard.TestFTP.basicFileList(TestFTP.java:224)

Also, any reason why the junit dependency was changed from test to compile?

@ijokarumawak
NIFI-4069: Make ListXXX work with timestamp precision in seconds or m…
49650ee 
…inutes

- Refactored variable names to better represents what those are meant for.
- Added deterministic logic which detects target filesystem timestamp precision and adjust lag time based on it.
- Changed from using System.nanoTime() to System.currentTimeMillis in test because Java File API reports timestamp in milliseconds at the best granularity. Also, System.nanoTime should not be used in mix with epoch milliseconds because it uses arbitrary origin and measured differently.
- Changed TestListFile to use more longer interval between file timestamps those are used by testFilterAge to provide more consistent test result because sleep time can be longer with filesystems whose timestamp in seconds precision.
- Added logging at TestListFile.
- Added TestWatcher to dump state in case assertion fails for further investigation.
- Added Timestamp Precision property so that user can set if auto-detect is not enough
- Adjust timestamps for ages test
@ijokarumawak
NIFI-3332: ListXXX to not miss files with the latest processed timestamp
06bbe49 
Before this fix, it's possible that ListXXX processors can miss files those have the same timestamp as the one which was the latest processed timestamp at the previous cycle. Since it only used timestamps, it was not possible to determine whether a file is already processed or not.

However, storing every single processed identifier as we used to will not perform well.
Instead, this commit makes ListXXX to store only identifiers those have the latest timestamp at a cycle to minimize the amount of state data to store.
@ijokarumawak
NIFI-3332: ListXXX to not miss files with the latest processed timestamp
0c22512 
- Fixed TestAbstractListProcessor to use appropriate time precision.
  Without this fix, arbitrary test can fail if generated timestamp does
  not have the desired time unit value, e.g. generated '10:51:00' where
  second precision is tested.
- Fixed TestFTP.basicFileList to use millisecond time precision explicitly
  because FakeFtpServer's time precision is in minutes.
- Changed junit dependency scope to 'provided' as it is needed by
  ListProcessorTestWatcher which is shared among different modules.
@ijokarumawak
Copy link
Member Author

@bbende Thanks for reviewing this.

This PR is now rebased with the latest master. The last commit includes following changes.

The failing TestFTP.basicFileList has been added after I worked on this PR. It uses FakeFTPServer, which provides timestamp precision in minutes. Then this PR adds time precision auto detection by default. The file which was expected to be picked was not picked because it hadn't passed the required amount of lag time for minute precision. The test has been updated to use millisecond precision explicitly and also thread sleep has been added. The same error was confirmed in my environment, but it's been addressed.

Similarly, I found that TestAbstractListProcessor tests can fail due to luck of time unit setting, when generated timestamp does not have the desired time unit value, e.g. generated '10:51:00' where second precision is tested. This has been addressed, too.

Finally, the reason for changing junit dependency is ListProcessorTestWatcher. It resides in nifi-processor-utils and is used by the project and also nifi-standard-processors project. In order to share ListProcessorTestWatcher via nifi-processor-utils, I changed junit scope to 'compile' because it needs to be accessible from the 'main' source, not by 'test' source. But 'provided' is more reasonable in this case, so I've updated it to 'provided'. Without having a mechanism like ListProcessorTestWatcher, debugging test failures will be very difficult, especially if it happens occasionally in a remote environment such as Travis CI.

@bbende
Copy link
Contributor

bbende commented Aug 28, 2017

Thanks for updating the PR! This looks good now, going to merge to master

@asfgit asfgit closed this in e68ff15 Aug 28, 2017
@jskora
Copy link
Contributor

jskora commented Aug 29, 2017

@ijokarumawak @bbende Sorry I haven't kept up with this recently. I'm happy to say that I was able to do some preliminary testing and this appears to solve the problem! Thanks!

🥇

@ijokarumawak
Copy link
Member Author

@jskora Thanks for sharing your test result, glad to hear that worked!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
3 participants
@ijokarumawak @bbende @jskora