hms-networks / flexy-canary-connector Goto Github PK

Possibly make the repo public
Make a release, test, and send to [Customer Rep]

no -configuration options, that is blocked by #11

Move the construction of the RequestInfo object into CanaryDataPayloadManager, which will allow the data poster thread to focus more directly on its intended functionality.

In the initialize phase, verify config options.

Missing config options that do not have default values, should result in error message logged and return false from init.

Mandatory config options (need to check that user has modified from defaults)
url, username, password

Add the extension library logger functionality to specify an exception/throwable with a regular message to improve the API.

Verify success, and response, parse
Related to #1

This needs to be tested when the connector runs and connects

Current web documentation regarding configuration is already in review. It must be updated to reflect the new aggregation period field added along with the data/payload functionality.

See: 2f26c59

Test the functionality for loading the non-abstract portion of the connector config and the configuration file integrity verification system at startup.

Specific errors such as bad tokens should not be passed up to the data poster. Handle them in the request sender class. only pass up unknown errors.

The performance of Thread.yield() and Thread.sleep(long) should be investigated.

Thread.yield() is intended to signal to the OS that the thread can be suspended and immediately re-added to the ready queue, allowing other threads to run.

• The investigation should clarify whether the impact of Thread.yield() can result in indeterminate periods of delay, especially during scenarios where the other running threads may have a high-CPU load.

Thread.sleep(long) is intended to signal to the OS that the thread shall not run before the defined/specified time period has been met/passed. This is expected to be more predictable than Thread.yield() but still allow other threads to execute as necessary while the calling thread sleeps.

• The investigation should clarify whether the impact of short Thread.sleep(long) calls can result in the thread not being suspended by the OS, which necessitates the original need to use Thread.yield() to force OS-level rescheduling.
  • If the sleep interval is increased, does this resolve the issue? Is it a feasible solution?

Reference:
[1]: https://www.java67.com/2012/08/difference-between-yield-and-sleep-in.html
[2]: https://stackoverflow.com/questions/1600572/are-thread-sleep0-and-thread-yield-statements-equivalent
[3]: https://github.com/kifferltd/open-mika/blob/079bcf51dce9442deee2cc728ee1d4a303f738ed/core-vm/java/java/lang/Thread.java#L699
[4]: https://github.com/kifferltd/open-mika/blob/master/core-vm/src/native/java/lang/Thread.c#L582

Move the #connectorConfigLoad from the main class to the abstract level, so that it is required for connectors to implement, and that it can be managed.

• Incorrect request information going out
• Session manage did not resend request for expired token
• Change method name to more descriptive, SessionManger.refreshTokens()
• Ensure thread safety is used with session tokens
• return empty string on no tokens found
• Use config for dataset name instead of serial number

email customer with update mid-sprint