mqtt_port_to_vhost_mapping global parameter

[V Z]

Can mqtt_port_to_vhost_mapping global parameter be specified in rabbitmq.config, or is running rabbitmqctl post deployment the only option?

[Michael Klishin]

Runtime parameters are, as the name suggests, not taken from the config.

CLI tools and HTTP API are the only ways to manage them. You can find out what endpoints
are available specifically for mqtt_port_to_vhost_mapping by searching for "global" in [1]

(since it's a global runtime parameter and not a vhost-specific one).

1. https://rawcdn.githack.com/rabbitmq/rabbitmq-management/v3.7.2/priv/www/api/index.html

On Fri, Jan 26, 2018 at 2:12 AM, V Z <uvzu...@gmail.com> wrote:

Can mqtt_port_to_vhost_mapping global parameter be specified in rabbitmq.config, or is running rabbitmqctl post deployment the only option?

--
You received this message because you are subscribed to the Google Groups "rabbitmq-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-users+unsubscribe@googlegroups.com.
To post to this group, send email to rabbitmq-users@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

MK

Staff Software Engineer, Pivotal/RabbitMQ

[V Z]

Could this be changed/enhanced so that this mapping is [also] supplied via config?

[Michael Klishin]

This would go against the idea of runtime parameters being set at, well, runtime.

I am -1 on the idea. Honestly the extent to which the MQTT plugin is full of bastardized

one-off ideas is already really concerning to me.

On Mon, Jan 29, 2018 at 11:04 PM, V Z <uvzu...@gmail.com> wrote:

Could this be changed/enhanced so that this mapping is [also] supplied via config?

--

You received this message because you are subscribed to the Google Groups "rabbitmq-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-users+unsubscribe@googlegroups.com.
To post to this group, send email to rabbitmq-users@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[V Z]

Could you please explain why this mapping has to be a run time parameter?

[Michael Klishin]

It doesn't have to be a runtime parameter but when this feature was first discussed

it was decided that runtime parameters make most sense. They can be updated

using CLI tools or HTTP API while redeploying config file is a lot less convenient and flexible option.

On Tue, Jan 30, 2018 at 7:28 PM, V Z <uvzu...@gmail.com> wrote:

Could you please explain why this mapping has to be a run time parameter?

--

You received this message because you are subscribed to the Google Groups "rabbitmq-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-users+unsubscribe@googlegroups.com.
To post to this group, send email to rabbitmq-users@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[V Z]

I see. Are these parameters replicated across nodes in the cluster, or is every node supposed to be updated individually with the same mapping?

[Michael Klishin]

They are replicated, yes.

On Tue, Jan 30, 2018 at 7:48 PM, V Z <uvzu...@gmail.com> wrote:

I see. Are these parameters replicated across nodes in the cluster, or is every node supposed to be updated individually with the same mapping?

--

You received this message because you are subscribed to the Google Groups "rabbitmq-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-users+unsubscribe@googlegroups.com.
To post to this group, send email to rabbitmq-users@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[V Z]

And persisted to some repository like Mnesia? 

So, in a way, using parameters is better than config because config is not replicated?

[Michael Klishin]

They are not different from non-global runtime parameters [1].

Primary reason why runtime parameters, global or per-vhost, exist is because some things

have to be configured without restarting the node. Cluster name and policies were the first two use cases for runtime

parameters IIRC.

1. http://www.rabbitmq.com/parameters.html

On Tue, Jan 30, 2018 at 7:58 PM, V Z <uvzu...@gmail.com> wrote:

And persisted to some repository like Mnesia? 

So, in a way, using parameters is better than config because config is not replicated?

--

You received this message because you are subscribed to the Google Groups "rabbitmq-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-users+unsubscribe@googlegroups.com.
To post to this group, send email to rabbitmq-users@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[V Z]

Thank you. This makes it clear. I learned something new (and valuable) today.