Bump software.amazon.kinesis:amazon-kinesis-client from 2.6.0 to 3.0.1

[dependabot]

Bumps software.amazon.kinesis:amazon-kinesis-client from 2.6.0 to 3.0.1.

Release notes

Sourced from software.amazon.kinesis:amazon-kinesis-client's releases.

v3.0.1

What's Changed

• Update backward compatibility check script by @​akidambisrinivasan in awslabs/amazon-kinesis-client#1393
• Update version to 3.0.1-SNAPSHOT by @​akidambisrinivasan in awslabs/amazon-kinesis-client#1394
• Address KCLv3 issues from github by @​akidambisrinivasan in awslabs/amazon-kinesis-client#1398
• Fix checkpointOwner copy issue for multistream lease by @​chenylee-aws in awslabs/amazon-kinesis-client#1401
• Preparation for v3.0.1 by @​chenylee-aws in awslabs/amazon-kinesis-client#1402

Full Changelog: awslabs/amazon-kinesis-client@v3.0.0...v3.0.1

Release 3.0.0 of the Amazon Kinesis Client Library for Java

Changelog

For 1.x release notes, please see v1.x/CHANGELOG.md

For 2.x release notes, please see v2.x/CHANGELOG.md

---

Release 3.0.0 (November 06, 2024)

• New lease assignment / load balancing algorithm
  • KCL 3.x introduces a new lease assignment and load balancing algorithm. It assigns leases among workers based on worker utilization metrics and throughput on each lease, replacing the previous lease count-based lease assignment algorithm.
  • When KCL detects higher variance in CPU utilization among workers, it proactively reassigns leases from over-utilized workers to under-utilized workers for even load balancing. This ensures even CPU utilization across workers and removes the need to over-provision the stream processing compute hosts.
• Optimized DynamoDB RCU usage
  • KCL 3.x optimizes DynamoDB read capacity unit (RCU) usage on the lease table by implementing a global secondary index with leaseOwner as the partition key. This index mirrors the leaseKey attribute from the base lease table, allowing workers to efficiently discover their assigned leases by querying the index instead of scanning the entire table.
  • This approach significantly reduces read operations compared to earlier KCL versions, where workers performed full table scans, resulting in higher RCU consumption.
• Graceful lease handoff
  • KCL 3.x introduces a feature called "graceful lease handoff" to minimize data reprocessing during lease reassignments. Graceful lease handoff allows the current worker to complete checkpointing of processed records before transferring the lease to another worker. For graceful lease handoff, you should implement checkpointing logic within the existing shutdownRequested() method.
  • This feature is enabled by default in KCL 3.x, but you can turn off this feature by adjusting the configuration property isGracefulLeaseHandoffEnabled.
  • While this approach significantly reduces the probability of data reprocessing during lease transfers, it doesn't completely eliminate the possibility. To maintain data integrity and consistency, it's crucial to design your downstream consumer applications to be idempotent. This ensures that the application can handle potential duplicate record processing without adverse effects.
• New DynamoDB metadata management artifacts
  • KCL 3.x introduces two new DynamoDB tables for improved lease management:
    • Worker metrics table: Records CPU utilization metrics from each worker. KCL uses these metrics for optimal lease assignments, balancing resource utilization across workers. If CPU utilization metric is not available, KCL assigns leases to balance the total sum of shard throughput per worker instead.
    • Coordinator state table: Stores internal state information for workers. Used to coordinate in-place migration from KCL 2.x to KCL 3.x and leader election among workers.
  • Follow this documentation to add required IAM permissions for your KCL application.
• Other improvements and changes
  • Dependency on the AWS SDK for Java 1.x has been fully removed.
    • The Glue Schema Registry integration functionality no longer depends on AWS SDK for Java 1.x. Previously, it required this as a transient dependency.
    • Multilangdaemon has been upgraded to use AWS SDK for Java 2.x. It no longer depends on AWS SDK for Java 1.x.
  • idleTimeBetweenReadsInMillis (PollingConfig) now has a minimum default value of 200.
    • This polling configuration property determines the publishers wait time between GetRecords calls in both success and failure cases. Previously, setting this value below 200 caused unnecessary throttling. This is because Amazon Kinesis Data Streams supports up to five read transactions per second per shard for shared-throughput consumers.
  • Shard lifecycle management is improved to deal with edge cases around shard splits and merges to ensure records continue being processed as expected.
• Migration
  • The programming interfaces of KCL 3.x remain identical with KCL 2.x for an easier migration, with the exception of those applications that do not use the recommended approach of using the Config Builder. These applications will have to refer to the troubleshooting guide. For detailed migration instructions, please refer to the Migrate consumers from KCL 2.x to KCL 3.x page in the Amazon Kinesis Data Streams developer guide.
• Configuration properties
  • New configuration properties introduced in KCL 3.x are listed in this doc.
  • Deprecated configuration properties in KCL 3.x are listed in this doc. You need to keep the deprecated configuration properties during the migration from any previous KCL version to KCL 3.x.
• Metrics
  • New CloudWatch metrics introduced in KCL 3.x are explained in the Monitor the Kinesis Client Library with Amazon CloudWatch in the Amazon Kinesis Data Streams developer guide. The following operations are newly added in KCL 3.x:
    • LeaseAssignmentManager

... (truncated)

Changelog

Sourced from software.amazon.kinesis:amazon-kinesis-client's changelog.

Release 3.0.1 (November 14, 2024)

• #1401 Fixed the lease graceful handoff behavior in the multi-stream processing mode

• #1398 Addressed several KCL 3.0 related issues raised via GitHub

  • Fixed transitive dependencies and added a Maven plugin to catch potential transitive dependency issues at build time
  • Removed the redundant shutdown of the leaseCoordinatorThreadPool
  • Fixed typo THROUGHOUT_PUT_KBPS
  • Fixed issues in scheduler shutdown sequence

• Note: If you are using multi-stream processing with KCL, you need to use the release 3.0.1 or later.

Release 3.0.0 (November 06, 2024)

• New lease assignment / load balancing algorithm
  • KCL 3.x introduces a new lease assignment and load balancing algorithm. It assigns leases among workers based on worker utilization metrics and throughput on each lease, replacing the previous lease count-based lease assignment algorithm.
  • When KCL detects higher variance in CPU utilization among workers, it proactively reassigns leases from over-utilized workers to under-utilized workers for even load balancing. This ensures even CPU utilization across workers and removes the need to over-provision the stream processing compute hosts.
• Optimized DynamoDB RCU usage
  • KCL 3.x optimizes DynamoDB read capacity unit (RCU) usage on the lease table by implementing a global secondary index with leaseOwner as the partition key. This index mirrors the leaseKey attribute from the base lease table, allowing workers to efficiently discover their assigned leases by querying the index instead of scanning the entire table.
  • This approach significantly reduces read operations compared to earlier KCL versions, where workers performed full table scans, resulting in higher RCU consumption.
• Graceful lease handoff
  • KCL 3.x introduces a feature called "graceful lease handoff" to minimize data reprocessing during lease reassignments. Graceful lease handoff allows the current worker to complete checkpointing of processed records before transferring the lease to another worker. For graceful lease handoff, you should implement checkpointing logic within the existing shutdownRequested() method.
  • This feature is enabled by default in KCL 3.x, but you can turn off this feature by adjusting the configuration property isGracefulLeaseHandoffEnabled.
  • While this approach significantly reduces the probability of data reprocessing during lease transfers, it doesn't completely eliminate the possibility. To maintain data integrity and consistency, it's crucial to design your downstream consumer applications to be idempotent. This ensures that the application can handle potential duplicate record processing without adverse effects.
• New DynamoDB metadata management artifacts
  • KCL 3.x introduces two new DynamoDB tables for improved lease management:
    • Worker metrics table: Records CPU utilization metrics from each worker. KCL uses these metrics for optimal lease assignments, balancing resource utilization across workers. If CPU utilization metric is not available, KCL assigns leases to balance the total sum of shard throughput per worker instead.
    • Coordinator state table: Stores internal state information for workers. Used to coordinate in-place migration from KCL 2.x to KCL 3.x and leader election among workers.
  • Follow this documentation to add required IAM permissions for your KCL application.
• Other improvements and changes
  • Dependency on the AWS SDK for Java 1.x has been fully removed.
    • The Glue Schema Registry integration functionality no longer depends on AWS SDK for Java 1.x. Previously, it required this as a transient dependency.
    • Multilangdaemon has been upgraded to use AWS SDK for Java 2.x. It no longer depends on AWS SDK for Java 1.x.
  • idleTimeBetweenReadsInMillis (PollingConfig) now has a minimum default value of 200.
    • This polling configuration property determines the publishers wait time between GetRecords calls in both success and failure cases. Previously, setting this value below 200 caused unnecessary throttling. This is because Amazon Kinesis Data Streams supports up to five read transactions per second per shard for shared-throughput consumers.
  • Shard lifecycle management is improved to deal with edge cases around shard splits and merges to ensure records continue being processed as expected.
• Migration
  • The programming interfaces of KCL 3.x remain identical with KCL 2.x for an easier migration, with the exception of those applications that do not use the recommended approach of using the Config Builder. These applications will have to refer to the troubleshooting guide. For detailed migration instructions, please refer to the Migrate consumers from KCL 2.x to KCL 3.x page in the Amazon Kinesis Data Streams developer guide.
• Configuration properties
  • New configuration properties introduced in KCL 3.x are listed in this doc.
  • Deprecated configuration properties in KCL 3.x are listed in this doc. You need to keep the deprecated configuration properties during the migration from any previous KCL version to KCL 3.x.
• Metrics
  • New CloudWatch metrics introduced in KCL 3.x are explained in the Monitor the Kinesis Client Library with Amazon CloudWatch in the Amazon Kinesis Data Streams developer guide. The following operations are newly added in KCL 3.x:
    • LeaseAssignmentManager
    • WorkerMetricStatsReporter
    • LeaseDiscovery

Commits

• 01d0e5c Preparation for v3.0.1 (#1402)
• 3facf30 Fix checkpointOwner copy issue for multistream lease (#1401)
• b154acf Address KCLv3 issues from github (#1398)
• 004f6d3 Update version to 3.0.1-SNAPSHOT (#1394)
• f7e909c Update backward compatibility check script (#1393)
• fbfd74d Release v3.0.0 (#1392)
• a159fa3 Bump com.google.protobuf:protobuf-java in /amazon-kinesis-client (#1383)
• 0478575 bugfix: debug or trace logging level now properly logs all worker loops (#1372)
• 1c0c41c Add config to enable PITR (#1365)
• 5878ba8 Add a backwards compatibility check for .proto files (#1362)
• Additional commits viewable in compare view

You can trigger a rebase of this PR by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)