[
https://issues.apache.org/jira/browse/DISPATCH-630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15853877#comment-15853877
]
Rob Godfrey commented on DISPATCH-630:
--------------------------------------
{quote}
I dont see how you are going to implement the existing (before this JIRA, but
since incorporated by this JIRA by extending the same mechanism) behaviour
without doing that. For the new MQTT-like behaviour the same may be true (one
slightly different option would be to broadcast arrival of the new connection
and have that sever any existing ones, however that probably doesn't give the
behaviour actually desired by the MQTT spec, and you could risk different
connections at similar time to distributed nodes causing each other to be
disconnected erroneously).
As above, it was always my expectation noone could have enforced these systems
to implement the behaviour. That another somewhat related behaviour has come up
somewhat changes things if they share the same mechanism. Maybe they shouldnt.
{quote}
I don't think the new behaviour changes the necessity to do this or not. My
observation is only that any behaviour around connection uniqueness will
require an agreement in a cluster, and that this is necessarily expensive... so
if a given client is not expecting the server to detect or enforce uniqueness
then we should not be expecting the server (or cluster) to try to detect it.
I'd be happy to move from simply saying "undefined" to saying that the server
side should make a best efforts basis attempt to check for duplication, but in
the case that all connections of a given container-id do not request sole
connection status it is not *guaranteed* that the server will enforce it.
{quote}
Yes having different clients using the same 'clientid' as it were would be
silly when they should be using different ones, but as guarding agaisnt
particualr behaviour when that happens is precisely why the mechanism exists,
so it feels to me it should actually do so and defining it to act otherwise (or
not saying what it does) seems off.
{quote}
sure - but you've already said that you don't actually expect clustered servers
to actually implement this properly :-) By saying it is undefined in the spec,
I am expecting that on a single node server, you probably would detect the
collision (because it is cheap to do so), but in the cluster/network case you
wouldn't (because it is expensive). In the case of an MQTT and JMS client
clashing, you are going to see an unexpected failure at one of the clients and
it's probably just a matter of timing which one sees the failure anyway. As
such I don't think it actually matters from a correctness view how we specify
it because in the case you worry about you would see an error of some kind, and
would need to fix it. My inclination is simply to define the spec to be the
least burden on the server side to implement correctly.
> 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]
