[
https://issues.apache.org/jira/browse/DISPATCH-630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15853742#comment-15853742
]
Robbie Gemmell commented on DISPATCH-630:
-----------------------------------------
{quote}
The behaviour when a client establishes connections without the desired
capability and then establishes a connection desiring this capability is not
defined (i.e. the server only needs to be able to look up connections where
this capability was explicitly desired).
{quote}
I actually think it is defined. In particular, the existing mechanism already
in place for JMS isnt really effective unless that behaviour is defined. We
even incorporated it into the capability name.
I think it would probably be further required to define here that an existing
connection which requested sole of the container use but didnt use the property
to request prior connections be dropped, also cant then be dropped for a
connection that later does, since doing so would be violating the contract
agreed with the earlier connection.
Some more details of the JMS mechanism for completeness, are: If the server
fails the connection attempt, we specified it should add a symbol keyed boolean
property of "amqp:connection-establishment-failed" as a hint that the Open has
failed and a Close will follow immediately with the reason (since the spec has
no way to convey that scenario, unlike with Attach/Detach where it does by
setting the appropriate source/target as a null). We also specified it should
add an entry to the Close error info map to hint that the container-id was the
cause, by adding an symbol key/value of "invalid-field"/"container-id",
allowing the client to specifically throw InvalidClientIDException as required.
> 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]
