vernemq
vernemq copied to clipboard
vernemq
[Proposal]: Simplify/improve the terminology around listener management
Describe your issue or feature request
Currently, in VerneMQ CLI, the management of the listeners seems somewhat confusing. You can "stop" a listener but it doesn't really stop it since you cannot start the same Address/Port combination again because it will return{already_started, Pid} even if the vmq_admin listeners show command presents the listener as "stopped". In that case, one needs to restart the listener to really start it again.,
Describe the solution you'd like
As a simplified, less confusing terminology, I propose that vmq_admin listeners stop ... really stops the listener, killing all the sessions, and removing the listener from the show output, and that way start can work again. Also, remove the restart command and replace it with:
vmq_admin listeners suspend ...: Does not kill connections but suspends any new connections.vmq_admin listeners resume ...: Starts receiving connections again on a suspended listener, do nothing on others.
Probably remove the vmq_admin listeners delete ... command too since stop will signify this.
Describe alternatives you've considered
No response
Environment
No response
Add any other context, code samples or screenshots about the issue report here.
No response
Code of Conduct
- [X] I agree to follow the VerneMQ's Code of Conduct
The terminology was chosen a long time ago... I agree it lacks clarity.
suspend/resume is great. start/stop will work, maybe start/terminate too to avoid redefining stop.
After that it's more of a documentation issue. I don't think the commands are widely used in a scripted fashion (breaking things). In any case, better command terminology helps new users. So, adding my +1. Thanks for the idea, @codeadict !
:point_right: Thank you for supporting VerneMQ: https://github.com/sponsors/vernemq :point_right: Using the binary VerneMQ packages commercially (.deb/.rpm/Docker) requires a paid subscription.
