Increased CPU usage and pod handling multiple messages at the same time

[razzpoker50]

Summary

I have a working node application based on this discussion - #374 , where in I need to refresh the AWS credentials and create a new instance of the consumer once the credentials expire. As part of the flow, I am periodically checking if the credentials expire, stop and start the consumer again with the SQS client with updated credentials as part of the flow.

This is hosted on kubernetes and each pod runs the application and the SQS consumers inside a separate container. While load testing this I am running into a scenario where in the container is consuming way too much CPU as more time passes. Not really where exactly to start to debug such scenarios for increased CPU. Was also wondering if there is a UUID associated with the consumer that is created. That way I can double check if multiple consumers are being created instead of a single instance.

Also in the documentation I did read that only 1 message will be handled by the consumer ( unless it is a batch ) and I do see multiple messages being handled by the same container at the same exact milli second. Any insights on this would be great.

I have a feeling that creating a new consumer with the SQS client with updated credentials ( start --> stop --> SQS client with new credentials --> start ) is ending up creating multiple instances of consumers ( please correct me if I am wrong ). Would be a great feature addition to pass in the SQS client as part of the start event instead 🤔

Example

No response

[Surajxxx]

@razzpoker50 we are also facing the same issue. It would be helpful for us if you have found a way around?

[nicholasgriffintn]

Hey, sorry that I'm late replying, as with similar issues, there's not that we can do without a proper reproduction unfortunately.

There are simply too many variables at play.

If you can find an issue specifically with SQS Consumer then we'll look into it.

[nicholasgriffintn]

In terms of the suggestion for starting multiple consumers, this isn't really what we built the library for.

That said, I'll take note of the suggestion for looking into in the future.