qpid-dev mailing list archives

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

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

Rob Godfrey edited comment on DISPATCH-630 at 2/6/17 9:34 AM:
--------------------------------------------------------------

{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.
{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.  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.
 In particular this would mean that every connection establishment would need to utilize some
sort of global synchronization lock to guard against the case of two connections for the same
container-id being created "at the same time".
{quote}
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.
{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}
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.
{quote}

I'd like to define this behaviour somewhere in an AMQP specification too - I'm not sure whether
that should go in the same document as connection uniqueness, or in a separate document dealing
solely with "Connection establishment failure"


was (Author: rgodfrey):
{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.
{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.  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 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.
{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}
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.
{quote}

I'd like to define this behaviour somewhere in an AMQP specification too - I'm not sure whether
that should go in the same document as connection uniqueness, or in a separate document dealing
solely with "Connection establishment failure"

> 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