METRON-1728: Handle null values in config in Pcap backend more gracefully

[mmiklavc]

Contributor Comments

https://issues.apache.org/jira/browse/METRON-1728

I modified the ConfigOptions interface to provide the ability to handle default values similar to the Map interface. ie getOrDefault. For PcapJob, I only improved/changed the values we expect to be user-supplied, ie start time, end time, etc., so we don't throw NPE's if a value gets lost in translation. I think we should definitely still add some validation to users via both REST and the UI similar to what is done in PcapCLI.

Note: This PR is an improvement to existing functionality, not a regression fix.

Pull Request Checklist

For all changes:

• Is there a JIRA ticket associated with this PR? If not one needs to be created at Metron Jira.
• 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)?

For code changes:

• 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:

  mvn -q clean integration-test install && dev-utilities/build-utils/verify_licenses.sh 
  

• Have you written or updated unit tests and or integration tests to verify your changes?

• Have you verified the basic functionality of the build by building and running locally with Vagrant full-dev environment or the equivalent?

For documentation related changes:

n/a

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.
It is also recommended that travis-ci is set up for your personal repository such that your branches are built there before submitting a pull request.

[justinleet]

Nanotime isn't actually current time in nanos or anything objectively meaningful (and can vary by jvm or be negative or whatever). Check out https://docs.oracle.com/javase/7/docs/api/java/lang/System.html#nanoTime()

Particularly,

This method can only be used to measure elapsed time and is not related to any other notion of system or wall-clock time. The value returned represents nanoseconds since some fixed but arbitrary origin time (perhaps in the future, so values may be negative).

I'd just make it System.currentTimeMillis() and adjust, since I don't think there's a clean way to get a real nanos timestamp in Java (at least until 9, maybe)

[mmiklavc]

@justinleet good catch! Thanks.

[justinleet]

+1 by inspection. Thanks for the improvement!

[mmiklavc]

Closing as merged