LockManagerAcquireError: could not acquire a lock.

[Abhiram-DLVSS]

Hello @weyoss ,

Debug Error:

Error LockManagerAcquireError: Could not acquire a lock
    at node_modules\redis-smq-common\dist\src\lock-manager\lock-manager.js:125:40
    at tryCatcher (node_modules\standard-as-callback\built\utils.js:12:23)
    at node_modules\standard-as-callback\built\index.js:22:53
    at processTicksAndRejections (node:internal/process/task_queues:96:5)

We have a use case where we would like to use redis-smq library in two different projects which are connected to the same Redis server. Each project makes use of the Scheduling Messages feature. We observed that only consumers of one project are able to consume the messages from redis-smq-v7.1:global:12 while the other project's consumers are not working because of the LockManagerAcquireError.

We tried using the namespaces, but they didn't work as those don't apply to the global keys.

So, is there a way to make both projects use the same Redis server, but their consumers should only consume messages produced by their respective producers?

Thank you!

[weyoss]

@Abhiram-DLVSS Thank you for opening this issue.

Application namespace, which can be set using a configuration object, does not apply to redis-smq global keys. Scheduled messages from different namespaces are stored in a unique queue for scheduled messages.

If you are running many consumers at the same time, only one consumer at a time would be able to dispatch messages from scheduled messages queue (using background workers) and in such case the error you have shown is not expected. Could you please provide the steps to reproduce it?

[Abhiram-DLVSS]

Thank you for your response. It clears things up.

Regarding the error that I have highlighted, I got it when I printed the error before
https://github.com/weyoss/redis-smq-common/blob/75871d785b2d5fd957daa97b89c16df27e88fbd6/src/worker/worker-runner/worker-runner.ts#L46

To clarify, the error is not being thrown by the library. While debugging, I discovered that this error is preventing other consumers from working. Therefore, I have included it here to provide a clearer explanation of my situation.

[weyoss]

@Abhiram-DLVSS

To clarify, the error is not being thrown by the library. While debugging, I discovered that this error is preventing other consumers from working.

Then it is totally fine. That is the way the message queue is designed to work. Consumer background jobs are allowed to run from only one consumer instance at a time. When the consumer instance goes down, one of the other instances takes control and background jobs are launched from that instance.