[
https://issues.apache.org/jira/browse/DISPATCH-630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15853911#comment-15853911
]
Robbie Gemmell commented on DISPATCH-630:
-----------------------------------------
{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}
I think thats better, though obviously not great if what you are looking for is
such a guarantee. Better than nothing though...
{quote}
sure - but you've already said that you don't actually expect clustered servers
to actually implement this properly :)
{quote}
No I didn't, and you know it ;) I'd say "properly" is different from my
outlined 'at all' scenario, and in the case I described the client would at
least know what it could or could not expect from the server.
{quote}
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.
{quote}
I can see that, and mostly agree it maeks sense, howevever the behaviour as
described inclues non-JMS and non-MQTT clients too and I think there are cases
you wouldnt necessarily spot issues as quickly as desired [particularly with
current servers], which isn't very pleasing.
> 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]
