LavinMQ adds support for vhost limits
LavinMQ has added support for vhost limits. Even if you’re familiar with the concepts of exchanges, bindings, and queues, you may not know much about vhosts. So let’s get into the details of vhost limits in LavinMQ.
What is a vhost?
Vhosts, also known by their longer name of virtual hosts, are individual, uniquely named containers. Within each vhost container is a logical group of exchanges, connections, queues, bindings, user permissions, and other system resources. When configuring LavinMQ, at least one vhost is required, with the default being a slash (/).
How to create a vhost
The management portal is used to create vhosts, but the HTTP API or
lavinmqctl are also options. Virtual hosts can be seen from the admin tab when selecting virtual hosts. To create a new vhost, click the option “Add New Virtual Host”. Users are assigned depending on your current system requirements, and it is your option to assign different users if required. Keep in mind that new vhosts have a default set of exchanges but no other entries or user permissions.
Unique permissions can be assigned according to the user wherein different vhost and queues and exchanges can be created, so they only exist in one vhost. Exchanges, queues, and other resources are named inside the vhost container. Each vhost essentially becomes a LavinMQ mini-server. When a connection is established to the LavinMQ server, the client specifies the vhost within which it will operate.
Each vhost has unique users, policies, exchanges, and queues that are not shared with other vhosts. Essentially, vhosts act as virtual machines that allow for multiple secure applications through virtual, rather than physical, separation. Because the separation is virtual, it’s important to remember that the vhosts might affect the performance of other vhosts. For example, if one service is experiencing a traffic spike or has a bug issue, it may cause problems with the performance of other services.
Using vhosts in LavinMQ makes it possible to have many different brokers within a single instance. The same broker can be used while the environments are separated. For instance, separating the production environment on one vhost and a staging environment on another within the same broker instead of needing multiple brokers.
Users are granted permissions on one or more vhosts according to your system policy rather than automatically having global permissions. This ensures complete separation since all users, exchanges, queues, bindings, and so on for each vhost are unreachable from other vhosts. This means that vhosts are useful for separating multiple customers and avoiding naming collisions.
Max connections per vhost
Two common message queue errors are connection leaks and excessive numbers of queues. These two conditions can quickly use up all the RAM and CPU available, which can cause many user issues. To prevent these issues, LavinMQ allows developers to set a per-vhost limit of a maximum number of queues or concurrent connections on the vhost to a certain level.
Try your own LavinMQ instance free
CloudAMQP, the message broker host with more than ten years of experience hosting, tweaking, and maintaining services worldwide, created LavinMQ. Sign up via CloudAMQP for your free managed LavinMQ instance and start exploring LavinMQ.