-
Notifications
You must be signed in to change notification settings - Fork 281
Confluence and CloudWatch and multiple other failing tests fix #6348
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
Confluence and CloudWatch and multiple other failing tests fix #6348
Conversation
Signed-off-by: Santhosh Gandhe <1909520+san81@users.noreply.github.com>
…_V2 retry mode and requires using RetryStrategy instead. Signed-off-by: Santhosh Gandhe <1909520+san81@users.noreply.github.com>
….repeat() with RandomStringUtils.randomAlphabetic() to generate test data of correct size (25MB) instead of excessive repetitions (~288GB) Signed-off-by: Santhosh Gandhe <1909520+san81@users.noreply.github.com>
….repeat() with RandomStringUtils.randomAlphabetic() to generate test data of correct size (25MB) instead of excessive repetitions (~288GB) Signed-off-by: Santhosh Gandhe <1909520+san81@users.noreply.github.com>
Signed-off-by: Santhosh Gandhe <1909520+san81@users.noreply.github.com>
Signed-off-by: Santhosh Gandhe <1909520+san81@users.noreply.github.com>
Signed-off-by: Santhosh Gandhe <1909520+san81@users.noreply.github.com>
…or instances to be registered: Signed-off-by: Santhosh Gandhe <1909520+san81@users.noreply.github.com>
Signed-off-by: Santhosh Gandhe <1909520+san81@users.noreply.github.com>
Signed-off-by: Santhosh Gandhe <1909520+san81@users.noreply.github.com>
graytaylor0
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for all these fixes!
dlvenable
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for these changes!
| final Optional<SourcePartitionStoreItem> maybeAcquired = | ||
| objectUnderTest.tryAcquireAvailablePartition(sourceIdentifier, ownerId, Duration.ofSeconds(20)); | ||
| // Wait for partition to be available in DynamoDB Local before attempting to acquire | ||
| final Optional<SourcePartitionStoreItem>[] maybeAcquiredHolder = new Optional[]{Optional.empty()}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure this will actually fix the issue. I've tried this a few times and ended up disabling this test in #6328.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is still some sleep in that PR, which could add uncertainty. I am hoping, we can give it a try with this approach and see.
| void testValidAndInvalidOutputFormats() throws NoSuchFieldException, IllegalAccessException { | ||
| setField(DateProcessorConfig.class, dateProcessorConfig, "outputFormat", random); | ||
| // Use a string with invalid pattern characters (] and [ are reserved and will always fail) | ||
| setField(DateProcessorConfig.class, dateProcessorConfig, "outputFormat", "invalid[pattern]format"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should probably an @ParameterizedTest with a few different invalid formats provided.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, converted it now.
Thought of minimizing the changes but as I am touching this, I could as well do it 👍
|
|
||
| final ClientOverrideConfiguration.Builder configBuilder = ClientOverrideConfiguration.builder() | ||
| .retryPolicy(r -> r.numRetries(AwsConfig.DEFAULT_CONNECTION_ATTEMPTS)); | ||
| .retryPolicy(retryPolicy); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you know why this improves the tests?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think, it started with AWS SDK behavior/validation changes that made the consumer pattern incompatible with the default retry mode. They now changed the default retry mode to be ADAPTIVE_V2
https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/retry-strategy.html
Ideal fix is to move to using RetryStrategy but thats a bigger change so minimized the changes here by avoiding using the consumer pattern. https://sdk.amazonaws.com/java/api/latest/software/amazon/awssdk/retries/api/RetryStrategy.html
| for (int i = 0; i < thresholdConfig.getBatchSize(); i++) { | ||
| JacksonEvent mockJacksonEvent = (JacksonEvent) JacksonEvent.fromMessage("testMessage".repeat((int) thresholdConfig.getMaxEventSizeBytes())); | ||
| JacksonEvent mockJacksonEvent = | ||
| (JacksonEvent) JacksonEvent.fromMessage(RandomStringUtils.insecure().nextAlphabetic(messageSize)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you know why the repeat used so much memory?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see. It was because the original string was already long.
Signed-off-by: Santhosh Gandhe <1909520+san81@users.noreply.github.com>
dlvenable
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @san81 !
…earch-project#6348) Making the tests less flaky. More reliable. Avoiding possible Out of memory issue with large pay load generation.
…earch-project#6348) Making the tests less flaky. More reliable. Avoiding possible Out of memory issue with large pay load generation. Signed-off-by: Nathan Wand <wandna@amazon.com>
Description
Fixing two failing tests:
instead of excessive repetitions (~288GB)
Check List
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.