[
https://issues.apache.org/jira/browse/DISPATCH-630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15853922#comment-15853922
]
Robbie Gemmell commented on DISPATCH-630:
-----------------------------------------
{quote}I don't think we are actually saying different things at this point,
just looking at it from different perspectives.
In practice:
A server consisting of a single process should always check a new
connection against existing connections with the same container id... If there
exists a connection with the same container id, and either connection has the
sole use capability, then
if both connections desire the new connection to be refused, the new
connection should be refused
if both connections desire the existing connection to be terminated, the
existing connection should be terminated
if there is a mismatch between the desires of the old connection and the
new connection, then the new connection should be refused
In the case of a cluster/network server then cases 1 and 2 should be
honoured to the best of its abilities, and the behaviour of case 3 is
essentially undefined, though if both connections want some sort of uniqueness
but the nature of the failure case is different we would expect the server to
terminate one of the connections
I think implementation guidance should be given to the above effect, but that
spec should be written to allow for network/clusters to be compliant for the
case of well-behaved clients. Neither of us expects a network/cluster to be
able to actually fully implement connection uniqueness in the face of "badly
behaved" clients I think.
{quote}
Essentially, yes.
I think the main annoyance for me is that as originally outlined for the JMS
mapping, if the server response indicated it supported this mechanism, it was
expected (by me at least) that it was guaranteed to be enforced, and were we to
ever implement bits needed to do so, a check by the client or application could
enforce if it was, whereas the above allows for the server to say it supports
the mechanism and yet there still to be cases the container might be used by
another connection. However, I freely admit those are likely the same cases I
wouldnt have expected the mechanism to be implemented at all, so the chance of
the client getting what it wants likely increases, its just unfortunate the
certainty around the actual behaviour decreases.
> 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]
