[
https://issues.apache.org/jira/browse/DISPATCH-630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15853855#comment-15853855
]
Rob Godfrey commented on DISPATCH-630:
--------------------------------------
{quote}
The idea when creating the mechanism was to also consider non-JMS client
connections. For JMS we want to have sole use of the container-id otherwise we
arent really doing what is desired in terms of isolating the links used for
durable subscriptions etc, as non-JMS clients could then be operating on the
same links anyway, allowing the two to interfere with each other. Yes, it would
still stop different JMS connections using the same container-id but that alone
isn't sufficient to entirely satisfy the behaviour desired for JMS that lead to
the mechanism existing in the first place, partly defeating the point.
{quote}
But what you are describing here is a use-case where they are breaking the AMQP
definition of container-id. Now, obviously if we are just putting in a user
supplied value into the container-id, there's a better than even chance that
people will choose a non-unique id for their container, thus "breaking" the
AMQP spec (everyone using "container-id", or "client-id" or something). So the
question here is actually not really about the sole use capability per se, but
about how we try to guard against poor container-id choice.
Within our JMS client or MQTT converter we could decide to prepend the supplied
user supplied identifier with something we believe will add to uniqueness
("qpid-jms:<client-id>", "mqtt-client:<client-id>" or whatever)... Within the
AMQP definition of the capability though, I think we have to behave as if
people are following the AMQP specification, which says that if you use the
same container id you are acting as if you are the same entity...
> Detecting connections with the same container-id
> ------------------------------------------------
>
> Key: DISPATCH-630
> URL: https://issues.apache.org/jira/browse/DISPATCH-630
> Project: Qpid Dispatch
> Issue Type: Improvement
> Reporter: Paolo Patierno
> Priority: Minor
>
> Using the router in the EnMasse project and looking into the MQTT
> specification we have the following problem on the current EnMasse
> implemetation.
> The MQTT specification says the following ...
> Let's imagine that a client is connected to the broker with client id "1234"
> and that another client tries to connect with same client id. The broker will
> shut down the connection with first client opening the new one.
> Now with our MQTT support, the MQTT gateway can run as multiple instances
> (multiple pods) so this check can't be executed by the gateway locally
> because a client "1234" could connect to MQTT GW-1 and another client (always
> "1234") could connect to the MQTT GW-2 and the gateways don't know about each
> other. The common point they have is the router network inside EnMasse and
> the fact that for each MQTT client a new AMQP connection is created on the
> other side attaching a link with this name : $mqtt.to.<client-id>
> The following idea came ...
> If during the connection we use a container-id that is equals to the
> client-id, could the router have a feature for detecting connections with
> same container-id and providing a way to close the previous ones ?
> It should be an information shared (and cached ?) by routers in their
> inter-router protocol.
> If not at connection level, maybe at link attachment level ? (when two
> clients attach to the same $mqtt.to.<client-id> link)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
