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
Custom receive timeout for nack with SQS using JMS #75
Comments
Anyone? |
I am having the same issue. This solution or the ability to use the SQS Default Visibility Timeout would be nice. |
Same here, immediate re-delivery on NACK results in message quickly ending up in dead letter |
We are having the same problem. Using the default that is set on sqs seems to be better behavior. |
Same here. New news on this? |
Workaround on stackoverflow https://stackoverflow.com/a/55187272/1079659 |
Thanks for the workaround @cmyker! Downside is it affects all change visibility requests... but it solves my immediate issue. +1 for incorporating an option into the library |
See my answer here, I believe this is the most ideal way to keep This default behavior of the library is pretty strange though. If you were going to set it to 0 for every failed message by default, then why do we have |
For those who use spring-jms: I have just tested the @sedooe solution in my local environment with an elasticmq, and it worked.
And then:
I didn't like it too much, but it solves my problem. |
I think spring have much to learn with Akka/Alpakka, when it comes to messaging |
I'm glad it worked for you but this strange behavior is coming from this amazon-sqs-java-messaging-lib and has nothing to do with Spring. 🙂 |
Sorry, my mistake |
More than 2 years later still having to use the workaround :)? |
this is exactly what is perplexing us. we actually have been relying on the visibilityTimeout to give us a simple backoff strategy, only today have we realised that if there is an error downstream or in handling a particular message, the result of this forcing to no wait is that it will attempt to DOS the downstream service. at first and second looks this is very wrong :( |
I too am saddened that there is no fix for this yet. We process messages which involve calls to external apis which have rate limiting. when messages are retried due to rate limit errors, the immediate retries only exacerbate the problem and increase the chances that the message will quickly exhaust all the retries and fail completely. i investigated some of the options above. @sedooe's solution of overriding the ultimately, we are forced to go the route of forking the library and directly modifying the negative ack logic for now. would love to see this issue fixed. |
The behavior of negative acknowledgment is to change the visibility timeout of a received message to 0. Where the value of NACK_TIMEOUT is not configurable while creating the SQS Factory for JMS.
https://github.com/awslabs/amazon-sqs-java-messaging-lib/blob/master/src/main/java/com/amazon/sqs/javamessaging/acknowledge/NegativeAcknowledger.java#L99
When a message is received, and the processing fails (Listener method throws an error), the message is immediately received again. In most of the cases, the message can be processed with a certain delay.
Is it possible to configure it to not change the visibility timeout, so it respects the Queue's default Receive Timeout configuration?
PS - I originally asked on Stackoverflow
The text was updated successfully, but these errors were encountered: