Unresolved queue issues

Queues can be created as either transient or persistent.

• Persistent queues are named and will survive loss of connection between client and message broker. If the broker is backed by a database, the messages will even survive reboots of the broker
• Transient queues are known only by the client creating them and their communication counterparts, cannot be shared, and are lost if the connection with the broker is lost.

How does the coordination layer know that new queues should be created? Proposals:

• A request is sent on the general topic requesting a creation of a new queue, when a new Bitrepository participant connects. The request contains the ID of the queue to create.
• A request is sent on a dedicated coordination layer queue, which is created when the system starts. The request contains the ID of the queue to create.
• A persistent/named queue is created by formal request to the body managing the coordinating layer. Queues MAY be shared by several clients belonging to the same organisation (individual communications are identified by correlationId). non-persistent/transient queues may be created by clients on demand without intervention, but should be reused for further communications for performance reasons.

How do we handle queues for participants which leave the system? Proposals:

• The rarely happens, so queues are deleted by hand.

When will clients and pillars create private queues?

• Depending on the time it takes to create a new queue, different strategies may make sense (relevant combinations of clients/pillars queues can be created, when a new SLA is opened)