Re: [amqp] Groups - Enforcing Connection Uniqueness Version 1.0 - WD04 uploaded

[Alan Conway <aconway@redhat.com>]

Seems like a connection closed this way would require special handling by auto-reconnect - what would the right behaviour be?

What are the use cases for this?

I'm guessing one case is enforcing a single instance of some service. I foresee some problems with that:

1. in "refuse new" mode, if B has a stale notion that old-A is still connected, it will refuse new-A; result: no A at all.
2. in "close old" mode, if A is automatically re-connecting for other types of error (network, restart of B etc.) then multiple copies of A can cause an infinite re-connect loop, stealing each other's connections forever.
(Note that if you could externally guarantee never to start multiple copies of A, you wouldn't need the connection uniqueness feature.)

It takes time to detect loss of a connection, and there is no consistent before/after ordering between connection close and connection open as observed by different processes.  I have seen this in practice with the Qpid C++ broker's HA scheme: when a backup broker bounces or gets heartbeated out, the primary sometimes sees it reconnect *before* seeing it's previous connection disconnect. All you need is a moderately loaded network to see such effects.

On Fri, Apr 20, 2018 at 10:42 AM, Rob Godfrey <rgodfrey@redhat.com> wrote:

Document Name: Enforcing Connection Uniqueness Version 1.0 - WD04

---

Description
This document defines a mechanism by which two processes communicating
using AMQP v1.0 can ensure and enforce that there exists only a single open
AMQP connection between the two of them.
Download Latest Revision
Public Download Link

---

Submitter: Rob Godfrey
Group: OASIS Advanced Message Queuing Protocol (AMQP) TC
Folder: Working Documents
Date submitted: 2018-04-20 07:41:40
Revision: 3