[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=66294#comment-66294 ] Lorenz Quack commented on AMQP-126: ----------------------------------- Thanks for clarifying the intent. Since we seem to disagree about what the current wording means I suggest it should be changed to remove any ambiguity. Going from what you describe as the intent: What is interesting is that if the enforcing container uses the strong detection policy a remote node that does not implement this specification but is fully AMQP 1.0 compliant will have its connection refused (i.e., closed) with the "invalid-field"/"container-id" as the only indication as to why even though from an AMQP 1.0 point of view the given container-id is completely valid. The same thing can happen with both the weak and strong detection policy if the requesting container requests the "close-existing" policy while the existing connection does not implement this spec. > 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]