Connection descriptor store is not shared across brokers about mop HOT 7 CLOSED

Maybe we can store this message to pulsar metadataStore.

/cc @codelipenghui

from mop.

@liangyepianzhou This will introduce more workload on the metadata server since the connection can create and close frequently. My opinion is to use one broker to handling the MQTT topic under a namespace, this means all the topics under a namespace are maintained by one broker, so we don't need to share something between MQTT brokers. So that we can guarantee client ID uniqueness under a namespace.

from mop.

@codelipenghui this eliminates a large benefit of using Pulsar over a traditional broker which is high availability if this was to be enforced.

At the end of the day MQTT sessions are designed to be long lived. So for well behaved clients it shouldn't be a problem. Could always introduce QoS quotas for number of connection establishments if load on the metadata API is of concern.

from mop.

@josephglanville I have added some declarations on the MoP docs.

from mop.

Another problem with not sharing and/or storing the session is that the subscription info will be lost if the client connects to another broker or the broker restarts. This is particularly an issue when using cleanSession=0. This info could be stored in metadata store and fetched from a local cache for performance reason.

from mop.

Another problem with not sharing and/or storing the session is that the subscription info will be lost if the client connects to another broker or the broker restarts. This is particularly an issue when using cleanSession=0. This info could be stored in metadata store and fetched from a local cache for performance reason.

Hi, we have supported this already.

from mop.

@codelipenghui this eliminates a large benefit of using Pulsar over a traditional broker which is high availability if this was to be enforced.

At the end of the day MQTT sessions are designed to be long lived. So for well behaved clients it shouldn't be a problem. Could always introduce QoS quotas for number of connection establishments if load on the metadata API is of concern.

Hi @josephglanville
As merged #560 and #565, we have supported this in MoP cluster.

from mop.