Open glidester opened 8 years ago
Hi Tim,
Currently we are not working on an async version, but we add your feature request to our backlog for future consideration.
Thanks for the suggested option and pull request for not deleting S3 objects in DeleteMessage call. We will review the submission.
:+1: would prefer async S3 upload which triggers sending the SQS message via the handler
Same here. I am working on a spring-cloud-aws application. Spring-cloud-aws uses the async client.
Any updates?
Any updates?
@ebezdomnikov https://github.com/spring-cloud/spring-cloud-aws/issues/167#issuecomment-574391997
Hello. I have been using this for a while now, and i was wondering if there any plans to update the payload-offloading-java-common-lib-for-aws to support InputStreams instead of Strings when storing large files to s3. In my use case i know the files being sent are going to be large, and would like to be able to stream the messagebody to s3 instead of having to load the entire chunk of data into memory as a string.
Here is a PR to add async to payload offloading: https://github.com/awslabs/payload-offloading-java-common-lib-for-aws/pull/19 . I need reviewers, and not sure how to get anyone's attention in that repo. That support has a set of UTs along with it, and is fully consistent with the current design.
I also created a draft PR in this repo that is based on the async payload offloading change: https://github.com/awslabs/amazon-sqs-java-extended-client-lib/pull/79 . This also has a set of UTs, and is fully consistent with the current design. It is also fully asynchronous and non-blocking.
If the payload offloading async support is approved, we can move the other PR in this repo to ready state and work on it.
Anyone who is familiar with this repo, please let me know how I can kickstart this process.
Is there any plan to bring the extended client in line with the standard client and produce an async version (or is this not possible due to the interactions with s3)?
It would be helpful if I could configure the client not to delete the s3 component of the message on the message delete action. This would then leave me an audit log of all the messages I'd received and I could then use the life-cycle attribute of the bucket to clear out the older messages that I no longer wish to retain.
Thanks,
Tim