Memory leak using clustered Vert.X Application

46 views
Skip to first unread message

Jan Fengler

unread,
Aug 8, 2022, 5:38:30 AM8/8/22
to vert.x
Hello all,

we have a problem using distributed locks on a clustered vert.x application. We use distributed locks from vert.x, that are backed by hazelcast semaphores. For every Item that passes our system we create a new distributed lock and after the item is processed, the lock is no longer needed.
We observe that the SemaphoreProxy-instance does not seem to be deleted, if the corresponding semaphore itself is removed, so over time there are a lot of them in the cluster that do not seem to have any particular use but use memory (memory leak).

Currently we have implemented a method that removes those stale instances, but that does look like a clumsy workaround.

We have the following questions:
  • Why is vert.x using semaphores and not locks for that particular use?
  • Do locks have the same problem (we did not try that until now, but if not, it might be an easy fix)?
  • Does anybody know, how to have the SemaphoreProxy-Instances automatically removed after the locks are no longer used?

Thx
  Jan Fengler

Thomas SEGISMONT

unread,
Aug 8, 2022, 5:57:52 AM8/8/22
to ve...@googlegroups.com
Hi,



Le lun. 8 août 2022 à 11:38, Jan Fengler <Jan.F...@adviqo.com> a écrit :
Hello all,

we have a problem using distributed locks on a clustered vert.x application. We use distributed locks from vert.x, that are backed by hazelcast semaphores. For every Item that passes our system we create a new distributed lock and after the item is processed, the lock is no longer needed.
We observe that the SemaphoreProxy-instance does not seem to be deleted, if the corresponding semaphore itself is removed, so over time there are a lot of them in the cluster that do not seem to have any particular use but use memory (memory leak).

Currently we have implemented a method that removes those stale instances, but that does look like a clumsy workaround.

We have the following questions:
  • Why is vert.x using semaphores and not locks for that particular use?

A semaphore with one permit is comparable to a lock, and allows us to support calling acquire/release on different threads
 
  • Do locks have the same problem (we did not try that until now, but if not, it might be an easy fix)?

You would get the same problem if you create new locks for specific items in your application,
 
  • Does anybody know, how to have the SemaphoreProxy-Instances automatically removed after the locks are no longer used?

I don't believe Hazelcast has a way to expire semaphore objects if they haven't been used for some time.
You could ask them on their community channel.

Regards
 

Thx
  Jan Fengler

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/AM0PR08MB3537BCA528C4C012BCC476E88B639%40AM0PR08MB3537.eurprd08.prod.outlook.com.
Reply all
Reply to author
Forward
0 new messages