Skip to content

Spring DMLC - SQSSessionCallbackScheduler too many zombie threads #47

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

Open
yeshodhan opened this issue Nov 26, 2017 · 1 comment
Open

Comments

@yeshodhan
Copy link

yeshodhan commented Nov 26, 2017

We've been facing high CPU utilization after putting in SQS JMS based implementation on production.

The root cause turned out to SQS connectivity issues and the use of CacheLevel: CACHE_CONSUMER and a Fixed BackOff. Turns out CACHE_CONSUMER is too aggressive and even with an ExponentialBackOff, it will try to retry quite aggressively. After changing the CacheLevel to CACHE_CONNECTION, the CPU utilization is stable in our test environments.

We are facing another issue though. To simulate SQS connectivity issues, we kill the network connection and monitor using VisualVM. The no. of threads created for SQSSessionCallbackScheduler are quite high and they never exit.

See screenshot below:
screenshot 2017-11-26 11 12 54
screenshot 2017-11-26 11 21 18

After resuming network connectivity, the threads don't seem to go down and new threads are created after this point.

We are using Spring DMLC with the below configuration:

ConcurrentConsumers: 10
MaxConcurrentConsumers: 25
CacheLevel: CACHE_CONNECTION (1)
AcknowledgeMode: CLIENT
BackOff: Exponential ( InitialInterval: 5000, Multiplier: 1.5)
IdleConsumerLimit: 1
IdleTaskExecutionLimit: 5
ReceiveTimeout: 1000

Any help?

yeshodhan added a commit to yeshodhan/amazon-sqs-java-messaging-lib that referenced this issue Nov 26, 2017
@yeshodhan
Copy link
Author

I've created #48 to solve this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant