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

Asynchronous producers in Kinesis #1930

Open
kamaljoshi opened this issue Dec 4, 2018 · 7 comments
Open

Asynchronous producers in Kinesis #1930

kamaljoshi opened this issue Dec 4, 2018 · 7 comments
Labels
feature-request A feature should be added or improved.

Comments

@kamaljoshi
Copy link

Issue description

Currently Kinesis API within the AWS Ruby SDK only supports synchronous producers. While benchmarking internally we found the latency of put to be around 8ms on average. This seems a lot and ideally an application using Kinesis a lot will this quite fast. So, I was looking for asynchronous producers on Kinesis, it doesn't seem like Ruby MRI has a library that supports that. From Kinesis docs it seems like the performant way to use that is KPL but that has interfaces available only for Java so that rules it out.

Do you guys have any suggestion on this? I was thinking of implementing a side extension to the main lib that comes with aws-sdk-kinesis where the main thread just pushes the job onto a list which has a worker thread which takes care of publishing messages to Kinesis asynchronously. The current approach is a fire and forget approach where you won't get acknowledgement of message deliveries and can lead to dropped messages in case like when Kinesis's APIs are down.

Gem name

aws-sdk, aws-sdk-kinesis

Version of Ruby

Ruby: 2.4/2.5

@srchase srchase added the feature-request A feature should be added or improved. label Dec 4, 2018
@srchase
Copy link
Contributor

srchase commented Dec 4, 2018

Thanks for opening this issue.

Are you looking for something like this, but for use with Ruby?

Amazon Kinesis Producer

I've marked this as a feature request for the team to consider.

@kamaljoshi
Copy link
Author

kamaljoshi commented Dec 5, 2018

Yes, Something like KPL would be the best option. Considering that KPL's core lib is in C++, one option is to extend it using something like FFI and use that to expose Ruby interfaces.

Right now, I think the two options to do here are to do a futures like pattern with a lib like concurrent-ruby or the separate thread approach as mentioned.

If you guys don't have bandwidth, I can take this up if we can agree on the implementation.

@conrosebraugh
Copy link

Is this something that is under active development? My organization has similar needs and could benefit from this feature.

@pchaganti
Copy link

👍

@mullermp mullermp added the help wanted We are asking the community to submit a PR to resolve this issue. label Mar 20, 2020
@github-actions
Copy link

Greetings! We’re closing this issue because it has been open a long time and hasn’t been updated in a while and may not be getting the attention it deserves. We encourage you to check if this is still an issue in the latest release and if you find that this is still a problem, please feel free to comment or open a new issue.

@github-actions github-actions bot added the closing-soon This issue will automatically close in 4 days unless further comments are made. label Mar 21, 2021
@mullermp mullermp removed closing-soon This issue will automatically close in 4 days unless further comments are made. help wanted We are asking the community to submit a PR to resolve this issue. labels Mar 22, 2021
@github-actions
Copy link

Greetings! We’re closing this issue because it has been open a long time and hasn’t been updated in a while and may not be getting the attention it deserves. We encourage you to check if this is still an issue in the latest release and if you find that this is still a problem, please feel free to comment or open a new issue.

@github-actions github-actions bot added the closing-soon This issue will automatically close in 4 days unless further comments are made. label Mar 23, 2022
@mullermp mullermp removed the closing-soon This issue will automatically close in 4 days unless further comments are made. label Mar 23, 2022
@github-actions
Copy link

Greetings! We’re closing this issue because it has been open a long time and hasn’t been updated in a while and may not be getting the attention it deserves. We encourage you to check if this is still an issue in the latest release and if you find that this is still a problem, please feel free to comment or open a new issue.

@github-actions github-actions bot added the closing-soon This issue will automatically close in 4 days unless further comments are made. label Mar 24, 2023
@mullermp mullermp added no-autoclose and removed closing-soon This issue will automatically close in 4 days unless further comments are made. labels Mar 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request A feature should be added or improved.
Projects
None yet
Development

No branches or pull requests

5 participants