Azure-sdk-for-java: [BUG] Memory leak in ServiceBusReceiverAsyncClient close

Created on 6 Dec 2020  ·  3Comments  ·  Source: Azure/azure-sdk-for-java

Describe the bug
When an instance of ServiceBusReceiverAsyncClient is created two LockContainer instance fields are created.

Each variable (in LockContainer's constructor) subscribe to Flux in order to cleanup resources periodically. The lambda used in the cleanup uses the lock container instance itself, so Flux will keep referencing the lock container instance until the consumer is disposed.

The issue is that when ServiceBusReceiverAsyncClient is closed, the LockContainer variables are not being also closed, which causes a memory leak.

To Reproduce
In order to reproduce create a ServiceBusReceiverAsyncClient instance and repeatedly call close and start. Use Visual VM in order to track memory use with heap dumps.

This is the memory use pattern you should see (a slight but steady increase in memory use):
Screenshot 2020-12-05 at 23 53 01

And this is how the number of instances in the heap and their retained sizes will look like in time:
Screenshot 2020-12-05 at 23 55 07
Screenshot 2020-12-05 at 23 56 24

Expected behavior
LockContainer instances should be closed when the client is closed and therefore not leak into memory.

Setup (please complete the following information):

  • OS: Mac/Linux
  • IDE : IntelliJ
  • 7.0.0

Information Checklist
Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report

  • [X] Bug Description Added
  • [X] Repro Steps Added
  • [X] Setup information Added
Client Service Bus customer-reported question

All 3 comments

Hello, I just opened a PR with a fix for this issue: https://github.com/Azure/azure-sdk-for-java/pull/17993.

Please let me know if you need any changes or more information.

Best regards!

Thanks for checking the PR @conniey ! Can we expect a new release soon? Best regards!

@marciopd we will have a release in January.

Fixed by #17993

Was this page helpful?
0 / 5 - 0 ratings