gguptp opened a new pull request, #261: URL: https://github.com/apache/flink-connector-aws/pull/261
<!-- *Thank you for contributing to Apache Flink AWS Connectors - we are happy that you want to help us improve our Flink connectors. To help the community review your contribution in the best possible way, please go through the checklist below, which will get the contribution into a shape in which it can be best reviewed.* ## Contribution Checklist - The name of the pull request should correspond to a [JIRA issue](https://issues.apache.org/jira/projects/FLINK/issues). Exceptions are made for typos in JavaDoc or documentation files, which need no JIRA issue. - Commits should be in the form of "[FLINK-XXXX][component] Title of the pull request", where [FLINK-XXXX] should be replaced by the actual issue number. Generally, [component] should be the connector you are working on. For example: "[FLINK-XXXX][Connectors/Kinesis] XXXX" if you are working on the Kinesis connector or "[FLINK-XXXX][Connectors/AWS] XXXX" if you are working on components shared among all the connectors. - Each pull request should only have one JIRA issue. - Once all items of the checklist are addressed, remove the above text and this checklist, leaving only the filled out template below. --> ## Purpose of the change The split reader made one blocking GetRecords call at a time, so a slow or throttled call on one shard delayed every other shard on the reader. With many shards per reader and high call latency (for example, cross-region reads), each shard was polled far less often than the configured poll delay. By default, the split reader now makes non-blocking calls: 1. Each fetch() starts a GetRecords call (or a child shard discovery call) for every shard that is ready, not paused, and has no call in progress. 2. The fetch then returns the records of one completed call. If no call is complete, it waits until a call completes, a shard is ready, or wakeUp() is called, for at most 100 ms. Each shard has at most one call in progress, so the number of assigned shards bounds the calls in progress. New option flink.dynamodbstreams.getrecords.blocking (default false) keeps the previous blocking behavior. Both modes store the same split state, so a job can switch in either direction and restore from its last checkpoint. Details: - StreamProxy gets getRecordsAsync and listShardsWithFilterAsync, implemented with DynamoDbStreamsAsyncClient. They follow the blocking methods: the shard iterator store, the retry after ExpiredIteratorException, the read from TRIM_HORIZON after TrimmedDataAccessException, and the empty response after ResourceNotFoundException. - A call that fails after all SDK retries fails fetch(), as the blocking call does. - If a split is paused while its call is in progress, the reader holds the response until the split resumes and starts no second call for it. - The async client has the same region, credentials, endpoint override, user agent prefix, and retry strategy as the sync client. Its Netty HTTP client uses HTTP/1.1, because DynamoDB Streams does not support HTTP/2. - All split readers of a source reader now share one stream proxy, and the source reader closes it. The fetcher manager creates a new split reader each time it starts a fetcher, for example after all splits of the previous fetcher finished. A proxy per split reader created a new SDK client, HTTP client and Netty event loop each time. - The enumerator still uses only the sync client. ## Verifying this change Please make sure both new and modified tests in this PR follows the conventions defined in our code quality guide: https://flink.apache.org/contributing/code-style-and-quality-common.html#testing *(Please pick either of the following options)* This change is a trivial rework / code cleanup without any test coverage. *(or)* This change is already covered by existing tests, such as *(please describe tests)*. *(or)* This change added tests and can be verified as follows: *(example:)* - *Added integration tests for end-to-end deployment* - *Added unit tests* - *Manually verified by running the Kinesis connector on a local Flink cluster.* Testing: unit tests run on JDK 11, 17 and 21, and the existing reader tests run in both modes. A load test on Amazon Managed Service for Apache Flink (Flink 2.2, parallelism 512) read a stream with tens of thousands of shards from TRIM_HORIZON. It read about 30 hours of backlog at 200k-250k records/s and caught up in about 20 minutes. Once caught up, it made about the same number of GetRecords calls as the blocking reader on the same stream. ## Significant changes *(Please check any boxes [x] if the answer is "yes". You can first publish the PR and check them afterwards, for convenience.)* - [ ] Dependencies have been added or upgraded - [ ] Public API has been changed (Public API is any class annotated with `@Public(Evolving)`) - [ ] Serializers have been changed - [ x ] New feature has been introduced - If yes, how is this documented? (not applicable / docs / JavaDocs / not documented) --- ##### Was generative AI tooling used to co-author this PR? <!-- If generative AI tooling has been used in the process of authoring this PR, please change the checkbox below to `[X]` and replace the placeholder in the "Generated-by" line with the tool name and version. Otherwise remove the "Generated-by" line. See the ASF Generative Tooling Guidance for details: https://www.apache.org/legal/generative-tooling.html You are responsible for the quality and correctness of every change in this PR regardless of the tooling used. Low-effort AI-generated PRs will be closed. See https://flink.apache.org/how-to-contribute/contribute-code/#ai-assisted-contributions for the full guidance. --> - [ x ] Yes (please specify the tool below) Generated-by: Claude Code (Claude Opus 5.5) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
