Replies: 1 comment
-
I wonder if this is something that can happen in practice. As long as BullMQ instantiates the Redis connection, the "end" event would only be triggered when closing the Worker or Queue that instantiated said Redis connection. On the other hand, if the connection is instantiated outside of BullMQ, then yes, the "end" event is ignored, but basically, you should not close the Redis connection before you close the Queue or Workers instances to avoid issues. |
Beta Was this translation helpful? Give feedback.
-
Hello,
First of all, thanks for the work you are doing on this lib.
I have a question because I can't find any information in the documentation about this case. Using the following code to instanciate a
Queue
orWorker
(so lettingBullMQ
create theRedis
client):What happens if the
end
event is issued by theRedis
client? The IORedis documentation states that :In other words, the maximum number of attempts to reconnect to
Redis
is exceeded and the connection is lost. In this case, the node on whichBullMQ
is running is no longer useful and should be stopped. So I wanted to know if there was a mechanism to force the node to crash? Like in this example:In this way, it may be my particular case, but my cloud provider is able to automatically restart the nodes when these have been killed and most of the time, when redeploying the application, the new nodes reconnect perfectly to the Redis database.
Thank you in advance,
Nicolas
Beta Was this translation helpful? Give feedback.
All reactions