onebeyond / rascal

A config driven wrapper for amqp.node supporting multi-host connections, automatic error recovery, redelivery flood protection, transparent encryption / decryption and channel pooling.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Failed to assert vhost: Timeout of 1000ms exceeded

thaoula opened this issue · comments

Hi @cressie176,

Hope you are well.

Some of our developers are getting the following error when starting up their containers -

[:***@rabbitmq:15672](:***@rabbitmq:15672/) errored with: Timeout of 1000ms exceeded

Error: Failed to assert vhost: dev. :***@rabbitmq:15672/ errored with: Timeout of 1000ms exceeded    at /home/app/node_modules/rascal/lib/management/Client.js:16:19    at processTicksAndRejections (node:internal/process/task_queues:94:5)

Just wondering if you can point me in the right direction and let me know where this timeout is coming from? Where I can override it for the developers so that they encounter this issue less.

This only 1000ms timeout is the following -

management: {
      options: {
        timeout: 1000,
      },
 },

Should i override this setting?

Regards,
Tarek

Hi Tarek,

I don't usually bother asserting the vhost - it's really only useful locally if you can't test against the default vhost for some reason. It's also odd that you're receiving timeouts, as 1 second to make an HTTP request to what I assume is a local RabbitMQ container is rather a long time. I might be tempted to see whether there are a large number of old queues / exchanges in the container from previous tests, as this can sometimes cause RabbitMQ to be slow starting up.

If you can't increase Rabbit's startup time, you can try increasing the timeout option. This is passed through to superagent as the deadline option. You can read about it here

Hi @cressie176,

Thanks for replying.

We are not running any tests. It is just our api container starting up and connecting to the local rabbitmq container.

We use asset because our code generates the vhosts, queues etc on startup.

Is the timeout you are referring to the same as the above? ie. management.options.timeout or options.timeout on ConnectionConfig?

Regards,
Tarek

It's the management.options.timeout one