Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question about lifetime #110

Open
bjtaylor1 opened this issue Mar 19, 2024 · 1 comment
Open

Question about lifetime #110

bjtaylor1 opened this issue Mar 19, 2024 · 1 comment

Comments

@bjtaylor1
Copy link

Hello, this is more of a question than an issue as such, but I would like to know please about how to use the amqp client in a long running service.
This has a function that has called regularly on a schedule within the scope of a node.js program, which is run as a service (on ubuntu).
Is it advisable/more efficient to declare the AMQPClient and AMQPChannel in global scope, meaning I only have to connect once at the start of the program, and use them in the function that is called regularly, OR, is it better to declare a new client and channel inside the function?

If the former, is there a way of determining whether the channel is still connected, and reconnecting if not?
Or if the connection drops, does it have the ability to reconnect?

If the latter, is there any inefficiency associated with keep reconnecting again repeatedly?

@dentarg
Copy link
Member

dentarg commented Apr 10, 2024

It is good practice to re-use the client connection and channel to avoid connection churn (see more at https://www.rabbitmq.com/docs/connections).

However, it is also good practice (important) to separate publishing and consuming, see https://www.rabbitmq.com/docs/channels#flow-control

Lastly, if you do need to re-connect repeatedly (like on every request to your web application), you could consider using https://github.com/cloudamqp/amqproxy

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants