Child pages
  • Unresolved queue issues
Skip to end of metadata
Go to start of metadata

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)


  1. How about SLA specific topics.

  2. The suggestions seem reasonable enough. A few things to consider:

    • If we implement the suggestion that queues are created automatically by sending a message to a specifc queue or topic, then the service we implement to do this must be implemented very carefully. In particular, it should be at least as rbust and available as the requirements of the messagebus itself, or we will have introduced a weak point of the coordinating layer.
    • If queues and topics are administratively implemented, we need some sort of service to look up the created destinations. For Java this is expected to be JNDI (see e.g. []). Contrary for .NET, it seems the expected use is simply to use the destinations by name, in exactly the fashion frowned upon by the Java programming model, see []