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