qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robbie Gemmell (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DISPATCH-630) Detecting connections with the same container-id
Date Mon, 06 Feb 2017 10:59:41 GMT

    [ https://issues.apache.org/jira/browse/DISPATCH-630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15853836#comment-15853836
] 

Robbie Gemmell commented on DISPATCH-630:
-----------------------------------------

{quote}
I disagree because what you have here is a "client" that is behaving in an inconsistent manner.
If the client is behaving per the JMS mapping spec, it MUST set the desired capability, so
there is no issue. The notion of a container id is that it represents a single logical entity
... what you are describing is an entity that is changing its desires/nature over time.
{quote}

The idea when creating the mechanism was to also consider non-JMS client connections. For
JMS we want to have sole use of the container-id otherwise we arent really doing what is desired
in terms of isolating the links used for durable subscriptions etc, as non-JMS clients could
then be operating on the same links anyway, allowing the two to interfere with each other.
Yes, it would still stop different JMS connections using the same container-id but that alone
isn't sufficient to entirely satisfy the behaviour desired for JMS that lead to the mechanism
existing in the first place, partly defeating the point.

That said, it was always my assumption that since we can't force anyone to actually implement
this on their server, such situations could arise with particular servers and it would be
the applications/clients choice as to how to handle that, e.g one option being asserting whether
the server offered the capability or not (though we have yet to put in place a mechanism by
which this could be done by the client, rather than by inspection of the server behaviour
upfront). If the server is going to offer the capability and still permit other connections
to use the container-id, I'm not sure what the client/application could even do in that case
as it wouldnt really be possible to discern the behaviour it was actually getting at a given
time.
{quote}
I think enforcing that a distributed network needs to look up every connection (and remember
every connection) just in case the client is behaving in an inconsistent manner is too large
a burden to place on the server side... and I can see no use case for providing this support.
{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}
Again I disagree - The container-id represents a single entity... the behaviour here should
either be undefined or (since the client container has clearly changed its mind) the server
container should respect the most recent wish of the client. Again, in practice this should
never occur as the client will have a fixed mode of operation (JMS-like, MQTT-like, or doesn't
desire sole connection behaviour).
{quote}

If we were to say 'most recent client behaviour', then if a \[JMS\] connection requested sole
use without dropping existing connections, had that granted, and then another \[MQTT\] connection
is allowed to come along and kick it off despite this, that seems a unexpected and a little
unfair (given it arrived first, gets dropped anyway, and cant reconnect), and perhaps even
somewhat abusable. Making it unknown behaviour seems undesirable.

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.


> 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: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org


Mime
View raw message