[
https://issues.apache.org/jira/browse/DISPATCH-630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15853896#comment-15853896
]
Robbie Gemmell commented on DISPATCH-630:
-----------------------------------------
{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).
{quote}
Perhaps, but even taking that to be the case, they may not know they are doing
it, and thats at least partly what the mechanism is in place to prevent in the
case of the JMS client.
{quote}
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)...
{quote}
We could, though I'd probably prefer not to in the JMS case. It might be
simpler and more appropriate in the case of an MQTT adapter, where the client
has no idea about the AMQP stuff occurring elsewhere on its behalf, and there
arent several years of existing usage to account for changing.
{quote}
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...
{quote}
I dont think it actually says that, though I agree its how things are expected
to work given the model outlined. We've effectively got two similar but
different cases where we want to ensure the "client application" the spec gives
example of as a container as being essentially a lone connection at a time. I
dont think we satisfy that simply by saying the spec outlines things such that
this shouldnt happen.
> 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]
