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.

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

Use lockfile to coordinate access to binary executable #92

Merged

Conversation

skidder
Copy link
Contributor

@skidder skidder commented Feb 24, 2017

Fixes #91

The approach of creating & locking the executable file in a non-atomic way can lead to a race condition. Instead, we should use a dedicated lockfile to coordinate access to the executable.

@jghoman
Copy link

jghoman commented Mar 14, 2017

We're running into this as well. Can someone from AWS please review and commit?

@pfifer
Copy link
Contributor

pfifer commented May 3, 2017

Please confirm that we can use, modify, copy, and redistribute this contribution.

Thanks.

@skidder
Copy link
Contributor Author

skidder commented May 11, 2017

Yes, you can use, modify, copy, and redistribute this contribution.

@skidder
Copy link
Contributor Author

skidder commented May 12, 2017

@pfifer this PR is good to go, sorry for the lag in granting you permission to use it.

@pfifer pfifer merged commit af7d6be into awslabs:master May 15, 2017
@pfifer pfifer added this to the v0.12.4 milestone May 16, 2017
pfifer added a commit that referenced this pull request May 17, 2017
=== 0.12.4

==== Java

* Upgraded dependency on aws-java-sdk-core to 1.11.128, and removed version range.
  * [PR #84](#84)
  * [PR #106](#106)
* Use an explicit lock file to manage access to the native KPL binaries.
  * [Issue #91](#91)
  * [PR #92](#92)
* Log reader threads should be shut down when the native process exits.
  * [Issue #93](#93)
  * [PR #94](#94)

==== C++ Core

* Add support for using a thread pool, instead of a thread per request.
  The thread pool model guarantees a fixed number of threads, but have issue catching up if the KPL is overloaded.
  * [PR #100](#100)
* Add log messages, and statistics about sending data to Kinesis.
  * Added flush statistics that record the count of events that trigger flushes of data destined for Kinesis
  * Added a log message that indicates the average time it takes for a PutRecords request to be completed.

      This time is recorded from the when the request is enqueued to when it is completed.
  * Log a warning if the average request time rises above five times the configured flush interval.

      If you see this warning normally it indicates that the KPL is having issues keeping up. The most likely
      cause is to many requests being generated, and you should investigate the flush triggers to determine why flushes
      are being triggered.
  * [PR #102](#102)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants