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

Allow for a Graceful Shutdown of the Worker #109

Merged
merged 5 commits into from
Oct 26, 2016

Conversation

pfifer
Copy link
Contributor

@pfifer pfifer commented Sep 30, 2016

Add a new method to the worker requestShutdown that allows the worker to
gracefully shutdown all record processors. The graceful shutdown gives
the record processors a last chance to checkpoint before they're
terminated.

To use these new features the record processor must implement
IShutdownnotificationaware.

Some cleanup to try and make the state transitions of the record
processor more clear.

Add a new method to the worker requestShutdown that allows the worker to
gracefully shutdown all record processors.  The graceful shutdown gives
the record processors a last chance to checkpoint before they're
terminated.

To use these new features the record processor must implement
IShutdownnotificationaware.

Some cleanup to try and make the state transitions of the record
processor more clear.
@pfifer pfifer added this to the v1.7.1 Kinesis Client Library milestone Oct 4, 2016
Handle some possible race conditions during the shutdown process.

Added more comments clarifying the how shutdown works, and the race
conditions it can face.
Added some additional comments clarifying the shutdown check miss.
Updated the log message to include the the count awaiting final shutdown.
@pfifer pfifer merged commit 26e67a3 into awslabs:master Oct 26, 2016
pfifer added a commit to pfifer/amazon-kinesis-client that referenced this pull request Nov 3, 2016
* General
  * Allow disabling shard synchronization at startup.
    * Applications can disable shard synchronization at startup.  Disabling shard synchronization can application startup times for very large streams.
    * [PR awslabs#102](awslabs#102)
  * Applications can now request a graceful shutdown, and record processors that implement the IShutdownNotificationAware will be given a chance to checkpoint before being shutdown.
    * This adds a [new interface](https://github.com/awslabs/amazon-kinesis-client/blob/master/src/main/java/com/amazonaws/services/kinesis/clientlibrary/interfaces/v2/IShutdownNotificationAware.java), and a [new method on Worker](https://github.com/awslabs/amazon-kinesis-client/blob/master/src/main/java/com/amazonaws/services/kinesis/clientlibrary/lib/worker/Worker.java#L539).
    * [PR awslabs#109](awslabs#109)
    * Solves [Issue awslabs#79](awslabs#79)
* MultiLangDaemon
  * Applications can now use credential provides that accept string parameters.
    * [PR awslabs#99](awslabs#99)
  * Applications can now use different credentials for each service.
    * [PR awslabs#111](awslabs#111)
pfifer added a commit that referenced this pull request Nov 3, 2016
* General
  * Allow disabling shard synchronization at startup.
    * Applications can disable shard synchronization at startup.  Disabling shard synchronization can application startup times for very large streams.
    * [PR #102](#102)
  * Applications can now request a graceful shutdown, and record processors that implement the IShutdownNotificationAware will be given a chance to checkpoint before being shutdown.
    * This adds a [new interface](https://github.com/awslabs/amazon-kinesis-client/blob/master/src/main/java/com/amazonaws/services/kinesis/clientlibrary/interfaces/v2/IShutdownNotificationAware.java), and a [new method on Worker](https://github.com/awslabs/amazon-kinesis-client/blob/master/src/main/java/com/amazonaws/services/kinesis/clientlibrary/lib/worker/Worker.java#L539).
    * [PR #109](#109)
    * Solves [Issue #79](#79)
* MultiLangDaemon
  * Applications can now use credential provides that accept string parameters.
    * [PR #99](#99)
  * Applications can now use different credentials for each service.
    * [PR #111](#111)
@DavidDeCoding
Copy link

DavidDeCoding commented Feb 21, 2017

What is the difference between the shutdown and shutdownRequested? What is the use case for both of them? Can you provide an example for both? Do we need to call requestShutdown then shutdown or does requestShutdown should shutdown the worker as well? Thanks. @pfifer

@pfifer
Copy link
Contributor Author

pfifer commented Feb 27, 2017

@DavidDeCoding The shutdown method will terminate the worker, without giving the record processor any change to checkpoint. The requestShutdown method notifies the record processor, if it implements IShutdownNotificationAware, of the upcoming shutdown, and gives them a chance to checkpoint. requestShutdown will also shutdown the worker instance same as shutdown.

In general I would recommend using requestShutdown unless you have a need to shutdown without giving the record processor an explicit chance to checkpoint.

@pfifer pfifer deleted the graceful-shutdown branch February 27, 2017 16:37
@DavidDeCoding
Copy link

Thanks @pfifer. I thought so too.

jari-kujansuu added a commit to jari-kujansuu/spark that referenced this pull request Mar 6, 2020
…heckpoint - instance doesn't hold the lease for this shard" errors.

Spark's KinesisRecordProcessor to implement Kinesis IShutdownNotificationAware interface to be notified before processor will be shutdown so that it can update checkpoint before shutdown.

See more details from:
- awslabs/amazon-kinesis-client#79
- awslabs/amazon-kinesis-client#109
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.

2 participants