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] [Comment Edited] (QPID-7605) [Java Broker] [AMQP1.0] Container id uniqueness
Date Wed, 04 Jan 2017 17:04:58 GMT

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

Robbie Gemmell edited comment on QPID-7605 at 1/4/17 5:04 PM:
--------------------------------------------------------------

{quote}
So the info map is on the close... my comments were focussed on the open...
{quote}
Yep, just checking you din't mean using a special container-id in the response would be conveying
the same detail we added the close error info map for. Rather it would only be signalling
the 'close is about to arrive' behaviour, and the fact both  bits reference the container-id
here is unrelated.

{quote}
Given that we do not originally call out that the empty string should be treated as a special
"I'm sorry Dave, I'm afraid I can't do that" meaning I'm hesitant about saying that that in
itself should be enough to call out the fact that the connection is going to immediately close...
What we could say though is that we define a connection capability "EMPTY_CONTAINER_ID_ON_OPEN_FAILS"
or something such that if the capability is present and the container-id is not empty the
the initiator can be assured that the connection is not about to immediately close... and
if the capability is there and the container-id is the empty string then it knows that the
connection is about to close.
{quote}

Yes, thats why we went with the property originally to convey the impending close, as the
container-id behaviour had no definition around it like that in the original spec.We also
thought it could be used to the same end in any similar behaviour-specific mechanisms to the
ClientID scenario. Making it an even more general mechanism like this isn't something I'd
considered before, but that also makes sense. The only issue would be if anyone wanted the
actual container-id of the remote peer to help govern their subsequent behaviour in some way,
not sure how likely that is.



was (Author: gemmellr):
{quote}
So the info map is on the close... my comments were focussed on the open...
{quote}
Yep, just checking you din't mean using a special container-id in the response would be conveying
the same detail we added the close error info map for. Rather it would only be signalling
the 'close is about to arrive' behaviour, and the fact both  bits reference the container-id
here is unrelated.

{quote}
Given that we do not originally call out that the empty string should be treated as a special
"I'm sorry Dave, I'm afraid I can't do that" meaning I'm hesitant about saying that that in
itself should be enough to call out the fact that the connection is going to immediately close...
What we could say though is that we define a connection capability "EMPTY_CONTAINER_ID_ON_OPEN_FAILS"
or something such that if the capability is present and the container-id is not null the the
initiator can be assured that the connection is not about to immediately close... and if the
capability is there and the container-id is the empty string then it knows that the connection
is about to close.
{quote}

Yes, thats why we went with the property originally to convey the impending close, as the
container-id behaviour had no definition around it like that in the original spec.We also
thought it could be used to the same end in any similar behaviour-specific mechanisms to the
ClientID scenario. Making it an even more general mechanism like this isn't something I'd
considered before, but that also makes sense.

I see you've edited this already <removes question> :)

> [Java Broker] [AMQP1.0] Container id uniqueness
> -----------------------------------------------
>
>                 Key: QPID-7605
>                 URL: https://issues.apache.org/jira/browse/QPID-7605
>             Project: Qpid
>          Issue Type: Improvement
>          Components: Java Broker
>            Reporter: Keith Wall
>             Fix For: qpid-java-7.0
>
>
> The AMQP 1.0 protocol layer implementation must ensure that the AMQP Open performative
container-id is unique amongst existing established connections.
> As the JMS client id maps to the container-id, so this will fulfil the JMS requirement.
 
> https://docs.oracle.com/javaee/7/api/javax/jms/Connection.html#setClientID-java.lang.String-
> Note that the Qpid JMS Client requires the Close performative with an Error containing
a hint to generate to correct JMS exception.  How will the Qpid Broker know to do this?
> org.apache.qpid.jms.integration.FailedConnectionsIntegrationTest#testConnectWithInvalidClientIdThrowsICIDEWhenInvalidContainerHintPresent



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org


Mime
View raw message