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

[exporter/awskinesisexporter] fix in compressor crashing under heady load due non-safe thread execution #32589

Conversation

leorinat
Copy link
Contributor

Fixing a bug that made the execution panic when the load was high enough, specially if the payloads were not very tiny.

Testing:
Executed this with and without the fix locally using heavy load, then ran it in cloud servers using heavier load and a variety of payloads.

Copy link
Contributor

@MovieStoreGuy MovieStoreGuy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Considering that this is intended to resolve a potential race condition, if we can look at ensuring that this can not happen again with tests, or ensure that operations are atomic is the ideal here.
Could you help provide some additional tests, or protections that this will stop happening?

leorinat and others added 6 commits April 23, 2024 19:42
…com:leorinat/opentelemetry-collector-contrib into fix/compressor-kinesis-exporter-thread-safe

# Conflicts:
#	exporter/awskinesisexporter/internal/compress/compresser.go
#	exporter/awskinesisexporter/internal/compress/noop_compression.go
)

type bufferedResetWriter interface {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nicely done!

Copy link
Contributor

@jamesmoessis jamesmoessis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me, nice work!

@jcmackie
Copy link
Contributor

Considering that this is intended to resolve a potential race condition, if we can look at ensuring that this can not happen again with tests, or ensure that operations are atomic is the ideal here. Could you help provide some additional tests, or protections that this will stop happening?

It looks like there's a test that might satisfy this requirement here: https://github.com/open-telemetry/opentelemetry-collector-contrib/pull/32589/files#diff-280135a7ba6930827a3944b3ac3fdc236eed9dc619c336dd817d22c4bd73dc9cR125
Does that look good to you @MovieStoreGuy?

@MovieStoreGuy MovieStoreGuy merged commit dd361de into open-telemetry:main Apr 29, 2024
170 checks passed
@github-actions github-actions bot added this to the next release milestone Apr 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants