-
I have a custom application that uses BullMQ workers in sandboxed mode. I have 2 queues in use. These 2 queues are handled asynchronously in separate processes (sandboxed). I'm having trouble figuring out how to handle the DB connection. To be precise, it's more about when to close the DB. Right now, I'm using the following logic in my BullMQ processor entry point: export default async function Processor(job: Job<BaseJobData>) {
// create inversify container with all DB repo's and service classes that inject each other.
const container = await initContainer();
const connection = container.get<MikroORM<IDatabaseDriver<Connection>>>(
TYPES.DATABASE_CONNECTION
);
// create the Databse Context so we don't use the global DB context.
// Within this context, we execute the BullMQ Job with `performJob`.
await RequestContext.createAsync(connection.em, async function () {
await performJob(job);
});
// I would like to call `connection.close(true)` here so the worker process can exit gracefully
await connection.close(true);
} But when I call What logic would be necessary to not have dangling worker processes that keep a connection alive to the DB in the context of sandboxed BullMQ workers? Anyone got tips? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
I think the best is to create your connection outside of the processor so that it gets reused every time the process function is called, and then close the connection on the SIGINT event listener for the process: process.on('SIGINT', await function () {
await connection.close();
process.exit();
}); |
Beta Was this translation helpful? Give feedback.
I think the best is to create your connection outside of the processor so that it gets reused every time the process function is called, and then close the connection on the SIGINT event listener for the process:
https://nodejs.org/api/process.html#signal-events