OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

amqp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] (AMQP-126) Sole Connection Detection Policy needs clarification


    [ https://issues.oasis-open.org/browse/AMQP-126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=66298#comment-66298 ] 

Lorenz Quack commented on AMQP-126:
-----------------------------------

Thanks for your comments, Rob.

Regarding the wording of the strong detection policy, if I may make an innitial suggestion:

If the enforcing container uses the strong detection policy then for every connection
which is established, the enforcing container will check to see if the new connection
has a sole connection enforcement policy or an existing
connection exists between the two containers which has a sole connection
enforcement requirement (even if the new connection does not state such a requirement).
If either connection has a sole connection enforcement policy it will be enforced.
If both connections (the existing and the new connection) have a sole connection
enforement policy, the policy of the existing connection will be enforced.

> Sole Connection Detection Policy needs clarification
> ----------------------------------------------------
>
>                 Key: AMQP-126
>                 URL: https://issues.oasis-open.org/browse/AMQP-126
>             Project: OASIS Advanced Message Queuing Protocol (AMQP) TC
>          Issue Type: Bug
>          Components: Sole Connection
>    Affects Versions: soleconn-WD2
>            Reporter: Lorenz Quack
>
> I find Section 3.2.2 of the specification unclear.
> To wrap my brain around the rules and when a certain detection policy would trigger the enforement policy I consider 4 cases: an existing connection does/doesn't have sole connction enforement (SCE) permutated with the new connection having/not having SCE.
> Then my reading of the spec gives me this table:
>   | old conn |  new conn ||  "strong" | "weak"
> 1 | NO SCE   |  NO SCE   ||    no     |   no
> 2 | NO SCE   |     SCE   ||    no     |  yes
> 3 |    SCE   |  NO SCE   ||    yes    |   no
> 4 |    SCE   |     SCE   ||    yes    |  yes
> Do people agree with my reading of the spec?
> Was it intended this way?
> In the "strong" case I find the asymmetry between case 2 and 3 surprising.
> I find it surprising that the weak policy should trigger in case 2 where the "strong" policy does not.
> My guess is that the intention was that the strong policy also triggers in case 2.
> Overall, I find it hard to see a clear intention behind the two detectoin policies.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]