🦬 Bull Queues for Node Version 2

@karh I will upload a new version tonight or tmr. Best wait for that version. It will install everything automatically and properly releases db connections if you use a sandboxed thread.

1 Like

Done @karh

Best first to remove the V1 extension.
Then just run npm install wappler-bull-queues or use the Wappler extension installer.

If you run into any issues with the Redis connection then best define the Redis variables via ENV
https://github.com/tbvgl/wappler-bull-queues#optional-env-variables.

The bull extension automatically installs the advanced logger as well in case you did not install that one, yet. Logging is configured via ENV variables as well. If you just want pretty console logging add this to your ENV:

PRETTY_LOG=enabled
LOG_LEVEL=debug

You can find more options here:

The Bull extension has logging integrated, so you will see logs immediately as soon as you run some jobs or create queues.

1 Like

Thank you so much @tbvgl - super excited to try it out. Hopefully today. Will update.

1 Like

@tbvgl Is this based on BullMQ?

@tbvgl Sadly getting this error:

[ioredis] Unhandled error event: Error: connect ECONNREFUSED 127.0.0.1:6379
    at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1494:16)
    at TCPConnectWrap.callbackTrampoline (node:internal/async_hooks:130:17)
[ioredis] Unhandled error event: Error: connect ECONNREFUSED 127.0.0.1:6379
    at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1494:16)
    at TCPConnectWrap.callbackTrampoline (node:internal/async_hooks:130:17) 

I installed using npm.

I’m guessing this should be fixed, isn’t it the issue from this thread?

EDIT Fixed by adding the REDIS_HOST config var image

Preformatted textAfter pulling the latest update I’m seeing

[ioredis] Unhandled error event: Error: connect ECONNREFUSED 127.0.0.1:6379 at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1494:16)

again. I ensured the sockets.js matched was was in Socket Error in Library Actions Any ideas or what to look at to debug?

@karh are you still getting errors after defining the creds via ENV?

@umadmin did you try using env variables for your connection parameters?

I think I’m going to depreciate connection parameters from globals and only allow ENV creds in the future.

server_connect.zip (15.0 KB)

@karh can you test if this one works for you without env variables?

1 Like

no, OptimalBits/bull because MQ requires typescript.

I’m not using environment variables. Can you provide what the parameters should be if leveraging the standard wappler config?

@umadmin You will need to use ENV variables as documented in the GH repo or you can try this fix for global configs from Wappler:

1 Like

That’s my question though. If leveraging the default wappler redis config what should the settings be for things REDIS_PORT, REDIS_HOST, REDIS_USER, etc. Which are required?

That depends on your Wappler redis config. Can you share the connection string from server connect?

I think the current default if you manage redis via Wappler would be just:

REDIS_HOST=redis

Yes this is the default

Yeah then you can use the ENV from above or try the zipped code.

The zipped code fixed the error. I also added the environment variable

2 Likes

Sorry gotta go, but it seems that umadmin tested it :smiley:

Appreciate the quick support on your extension btw :slight_smile:

1 Like

Thanks guys, I pushed V1.8.3 with the fix https://www.npmjs.com/package/wappler-bull-queues/v/1.8.3

npm update or using the Wappler package update button will automatically install the newer version.

3 Likes

Btw quick reminder here: If you use queues in sandboxed threads then every new job will create a new DB connection. They get automatically destroyed when the job is done. But if you run a lot of concurrent jobs in sandboxed threads and use Postgres then make sure to put pgbouncer in front of it so that you don’t run out of connections. That way you can easily handle thousands of concurrent jobs if your server has the power.

1 Like